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I.  INTRODUCTION 


A.  IMPORTANCE  OF  OS  DETECTION 

The  Internet  today,  as  it  is  defined  in  the  book,  Computer  Networking— A  Top 
Down  Approach"  by  Kurose-Ross,  is  a  “network  of  networks”  [1].  This  worldwide 
network  eonsists  of  end  systems,  either  applieation  elients  or  servers,  and  the 
eommunieation  infrastrueture  that  intereonneets  them.  This  worldwide  network  provides 
the  digital  highway  for  the  wide  range  of  serviees  that  are  available  today,  and  makes  the 
Internet  an  attraetive  tool  with  a  vast  amount  of  users.  Although  this  network  was  built  to 
provide  serviees  to  users  with  goodwill,  it  has  beeome  a  target  of  malieious  attaeks. 

This  is  the  point  where  the  eoneept  of  network  seeurity  arises  with  the  ultimate 
aim  to  proteet  the  assets  of  this  network.  The  assets  in  the  Internet  eould  be  either  the 
deviees  that  make  up  the  Internet  or  the  data  that  are  stored  in  those  deviees.  Beeause  the 
Internet  initially  was  not  built  with  great  coneern  for  seeurity,  over  the  years  it  has 
evolved  to  eliminate  the  vulnerabilities  and  provide  its  users  the  appropriate  level  of 
assuranee.  Similarly,  the  end  systems  have  been  under  the  same  evolution,  and  the  effort 
was  to  develop  operating  systems  (OSes)  that  would  be  self-proteeted  and  tamper-proof 
Nevertheless,  vulnerabilities  still  exist  in  the  systems  today  and  may  still  exist  in  the 
future  No  matter  how  hard  it  is  to  identify  vulnerabilities,  there  are  people  devoted  to 
reveal  them  and  either  to  eorreet  the  problem  by  performing  the  appropriate 
modifieations  on  the  software  or  to  exploit  them  by  staging  attaeks. 

All  eomputer  systems  today  run  an  operating  system,  and  there  are  a  variety  of 
OSes  from  whieh  to  ehoose.  Beeause  these  OSes  have  been  developed  by  different 
vendors,  they  have  been  implemented  aeeording  to  their  developers’  own  philosophy 
about  how  to  best  provide  assuranee  to  their  users  and  proteet  the  data  they  store.  Until 
the  time  when  an  absolutely  seeure  system  with  no  vulnerability  is  developed,  all  OSes 
will  have  vulnerable  points  with  the  potential  to  be  exploited.  Those  vulnerabilities  are,  in 
faet,  weak  points  in  the  software  of  the  OS,  and  this  is  the  reason  that  makes 
vulnerabilities  OS  speeifie.  Different  OSes  will  have  different  vulnerabilities,  and  if 
someone  wishes  to  take  advantage  of  them,  he  will  probably  need  to  follow  a  different 
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approach  depending  on  the  OS  being  attaeked.  Moreover,  the  OS  is  the  software  platform 
for  several  other  applieations,  whieh  may  also  have  their  own  vulnerabilities  that  ean  be 
exploited  to  take  control  of  a  system  or  perform  malieious  aetions  on  that  system. 

So,  we  come  to  the  eonclusion  that  the  knowledge  of  the  OS  type  and  the  serviees 
running  on  a  system  are  the  key  factors  for  deciding  the  appropriate  methods  for 
attaeking  a  given  system.  To  date,  a  variety  of  teehniques  have  been  explored  to  remotely 
identify  the  OS  type  over  the  Internet  and  a  number  of  tools  have  been  developed  to 
automate  the  proeess  and  make  it  much  easier.  However,  the  ability  to  identify  the  OS 
ean  also  be  used  for  defensive  purposes.  Network  administrators  should  be  aware  of  the 
importance  of  OS  detection  and  take  all  the  neeessary  measures  to  frustrate  this  threat. 
Thus,  one  way  to  verify  the  reliability  of  the  protection  measures  they  have  taken  is  to 
use  the  same  tools  against  their  own  network  and  determine  what  kind  of  information  is 
leaving  their  network  that  eould  reveal  the  OSes  running  on  their  maehines.  These  tools 
most  often  use  a  database  of  common  characteristics  associated  with  specific  OSes.  That 
means  a  database  must  be  developed  in  advance  with  which  to  compare  the  observed 
characteristics  of  an  OS  and  then  to  deduee  the  type  being  used.  Those  characteristics  are 
pretty  much  like  fingerprints  for  OSes  and  thus  the  overall  process  ean  be  defined  as  OS 
fingerprinting. 


B,  THESIS  OBJECTIVES 

The  Internet  today  implements  the  IP  version  4  protoeol  within  the  network  layer 
of  the  protocol  stack,  as  it  is  presented  in  Figure  1.  That  means  it  uses  the  Internet 
protocol  of  the  network  layer,  as  it  is  defined  in  RFC  791.  This  standard  deseribes  the 
datagram  format,  the  addressing  conventions,  and  the  packet  handling  conventions  of  the 
packets  or  datagrams  traversing  the  network  layer. 
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Application  Layer 
Transport  Layer 
Network  Layer 
Link  Layer 
Physieal  Layer 

Figure  1.  TCP/IP  protoeol  stack. 

The  most  important  characteristie  of  the  TCP/IPv4  protocol  stack  is  the 
addressing  part.  Today,  all  hosts  eonneeted  to  the  Internet,  in  order  to  be  able  to  send  and 
reeeive  datagrams,  need  to  have  an  IP  address.  Eaeh  IP  address  is  32  bits  long  and  is 
unique  for  every  interface  that  eonneets  a  host  to  the  Internet.  This  architecture  works 
very  well  and  provides  a  great  degree  of  effieieney.  However,  diffieulties  arise  from  the 
faet  that  the  address  space  defined  with  the  existing  32-bit  addressing  architeeture  has  an 
upper  bound.  It  ean  address  no  more  than  4.2  billion  hosts  f  Although,  this  is  a  relatively 
large  number  of  hosts,  with  the  current  rate  of  new  users  attaching  to  the  Internet,  it  has 
been  estimated  by  two  leaders  of  the  IETF  Address  Eifetime  Expeetations  working  group 
that  addresses  would  become  exhausted  in  2008  and  2018,  respectively  [2,3].  Clearly 
something  has  to  be  done  about  this.  Thus,  in  the  early  ’90s  the  lETE  began  an  effort  to 
develop  the  successor  of  the  IPv4  protoeol.  The  solution  is  the  IPv6  protocol  [4],  which 
probably  solves  the  address  space  limitation  once  and  for  all  but  also  introduees  a  few 
more  ehanges  based  on  experience  gained  from  IPv4. 

Based  on  the  fact  that  a  transition  from  IPv4  to  IPv6  will  occur  in  the  next  several 
years,  a  number  of  questions  arise  regarding  the  applieability  of  OS  fingerprinting  to 
IPv6.  Thus,  the  main  objeetives  for  this  thesis  are  the  following: 

•  Investigate  the  applicability  of  the  teehniques  used  eurrently  for  the  IPv4 
protoeol  to  the  fortheoming  IPv6. 


1  4.2  billions 
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•  The  IPv6  protocol  may  enable  new  methods  of  OS  fingerprinting.  A 
secondary  goal  of  this  thesis  is  to  identify  some  of  these  methods. 


C.  THESIS  OVERVIEW 

This  section  presents  briefly  the  contents  of  the  subsequent  chapters. 

1,  Chapter  II,  Background 

This  chapter  describes  the  approaches  available  today  for  detecting  the  OS  of  a 
remote  host  in  an  IPv4  environment  and  presents  the  available  methods  for  active  stack 
fingerprinting.  The  objective  of  the  information  presented  in  this  chapter  is  to  help  the 
reader  create  a  solid  base  around  the  concept  of  OS  detection  and  especially  of  OS 
fingerprinting. 

2,  Chapter  III,  Network  Configuration  and  Packet  Crafting 

In  this  chapter,  the  experimentation  network,  which  was  set  up  for  the  purpose  of 
the  thesis,  is  presented.  The  factors  on  which  the  selection  of  the  types  and  the  vendors  of 
the  OSes  included  in  the  network  were  based  are  also  described.  Finally,  it  describes  the 
packet  crafting  process  and  how  it  was  conducted  in  this  thesis. 

3.  Chapter  IV,  Testing  Of  Existing  IPv4-Based  Methods 

Two  tools  available  today  for  OS  detection,  Nmap  and  Queso,  were  explored  and 
used  for  OS  detection  in  the  test  network.  Nmap  seems  to  use  the  most  efficient  and 
complete  methods  for  OS  fingerprinting.  The  results  of  using  those  tools  with  the 
network,  in  order  to  have  a  baseline  of  OS  detection  in  IPv4  environment,  are  described. 
Then,  these  methods  are  tested  for  their  applicability  with  IPv6.  The  results  of  the 
implementation  of  each  method  on  the  selected  OSes  in  the  network  are  presented  in  a 
table  format  and  analyzed  in  order  to  find  identifying  factors  among  the  OSes. 

4.  Chapter  V,  OS  Detection  Methods  Enabled  hy  IPv6 

This  chapter  reports  an  attempt  to  identify  new  OS  detection  methods  enabled  by 
the  IPv6  protocol  itself.  New  methods  are  possible  because  a  lot  of  changes  were  made  to 
the  IP  architecture,  and  it  is  likely  that  new  identifying  factors  may  be  found  in  the 
implementation  of  the  new  protocol  by  different  OSes. 
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5,  Chapter  V,  Conclusions 

Finally,  the  results  from  the  tests  are  summarized  and  a  discussion  is  presented 
about  the  effectiveness  of  those  methods  into  IPv6.  This  chapter  also  discusses  possible 
ways  to  extend  this  research 


5 


THIS  PAGE  INTENTIONALLY  LEET  BLANK 


6 


II.  BACKGROUND 


This  chapter  will  provide  the  reader  with  a  solid  base  with  respect  to  the  OS 
fingerprinting  coneept  and  explore  the  approaches  taken  so  far  to  deteet  the  OS  resident 
on  a  system  of  interest.  This  is  important  because,  even  though  there  is  to  be  a  transition 
from  IPv4  to  IPv6,  it  is  possible  that  the  same  coneepts  used  for  OS  fingerprinting  in  the 
first  protoeol  can  be  used  in  the  seeond  as  well. 


A,  TYPES  OF  OS  DETECTION 

Several  different  approaehes  have  been  developed  for  detecting  the  OS  of  a  host. 
Eaeh  one  of  them  has  unique  pros  and  cons,  and  its  effectiveness  varies  from  OS  to  OS. 
The  basic  approaches  used  today  are  briefly  deseribed  below.  However,  they  eould  be 
eategorized  into  four  classes  based  on  the  type  of  information  they  use  to  identify  the  OS. 
The  first  two  are  looking  for  information  gathered  at  the  applieation  layer  level,  such  as 
which  ports  are  open  on  a  host  or  any  explieit  reference  from  the  application  about  the 
name  of  the  application  or  the  developer.  The  next  two  use  the  concept  of  “staek 
fingerprinting”[5,6],  whieh  looks  more  deeply  into  the  packets  sent  from  the  target  host 
and  attempts  to  determine  the  OS  by  examining  the  values  used  for  some  of  the  fields 
inside  the  various  layer  headers.  Beeause  a  specific  set  of  values  could  identify  the  OS, 
like  a  speeific  fingerprint  identifies  a  person,  we  refer  to  this  set  as  an  OS  fingerprint. 

1.  Port  Scanning 

Port  scanning  is  the  proeess  of  probing  the  TCP  and  UDP  ports  on  a  target  host  to 
identify  the  services  that  are  running  and  listening  for  incoming  connections.  Although 
this  is  not  explicitly  an  OS  detection  technique,  it  can  be  used  to  determine  the  type  and 
version  of  the  OS  [7].  This  is  because  many  serviees  are  known  to  run  on  specifie  types 
of  OS.  For  example,  the  NetBIOS  name  service  of  the  Windows  OS  listens  on  UDP  port 
137.  That  means  that  if  we  discover  this  port  open  on  a  host,  it  most  probably  is  running  a 
Windows  OS.  However,  this  technique  is  not  always  successful,  as  many  services  are 
eapable  of  running  on  different  OS  types.  For  example  the  Web  serviee  uses  the  HTTP 
application  layer  protocol,  which  is  identified  with  the  well-known  port  80.  This  port  is 
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the  same  for  every  host  used  as  a  publie  web  server.  In  this  ease,  identifying  that  port  80 
is  open  and  listening  for  ineoming  conneetions  does  not  say  too  mueh  about  the  type  of 
OS  on  the  host. 

Some  of  the  port  seanning  teehniques  used  today  are  deseribed  later  when  we 
diseuss  the  OS  deteetion  methods.  Beeause  most  of  these  teehniques  are  used  for  Aetive 
Staek  OS  deteetion,  the  differenee  lies  in  the  way  we  manipulate  the  results  found.  In  the 
ease  of  Port  Seanning,  we  are  looking  for  active  processes.  So,  if  we  attempt  to  establish 
a  TCP  connection  with  the  target  host  by  sending  a  SYN  packet,  then  that  machine  will 
send  back  either  a  RST/ACK  packet  if  the  port  is  closed  or  a  SYN/ACK  packet^  if  the 
port  is  open.  If  we  send  this  packet  in  sequence  to  all  ports  on  the  target  host,  we  can 
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discover  all  the  open  and  closed  ports  on  that  machine  . 

2,  Banner  Grabbing 

With  banner  grabbing,  we  simply  try  to  connect  to  applications  running  on  the 
target  host  and  observe  the  responses,  which  sometimes  may  reveal  very  useful 
information  as  to  the  exact  type  and  developer  of  the  application  [8].  However,  this  is  not 
always  effective.  The  type  of  information  leaving  a  host  is  often  configurable  and  many 
administrators  have  taken  care  of  this  when  setting  up  their  network.  So,  this  type  of  OS 
detection  is  most  effective  only  in  the  case  of  a  misconfigured  server. 

3,  Passive  Stack  Fingerprinting 

Passive  stack  fingerprinting  [9]  attempts  to  identify  the  OS  by  monitoring 
network  traffic  and  examining  the  values  set  for  some  of  the  fields  of  the  packets  sent 
from  the  target  host.  Some  of  these  fields  are  the  time  to  live  (TTL),  window  size,  initial 
sequence  number  (ISN),  the  don’t  fragment  (DF),  and  possibly  others.  Passive  stack 
fingerprinting  will  identify  the  values  set  for  these  fields  and  will  compare  them  with  a 
database  and  then  infer  the  OS  based  on  the  similarities.  This  means  that  we  must  have  a 
database  developed  in  advance  that  catalogs  OSes  by  a  set  of  values  for  those  attributes. 
This  approach,  although  it  can  be  performed  silently  without  leaving  any  trace,  has  a 
major  limitation  in  that  we  must  be  inside  the  network  for  which  we  want  to  see  the 
traffic. 

2  This  is  the  TCPconnect  scan  used  by  Nmap,  where  we  are  trying  to  attempt  a  full  three-way 
handshake  with  the  target  host. 

^  The  port  number  is  16  bits  long,  so  there  are  2*®  =  65535  different  ports. 
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4,  Active  Stack  Fingerprinting 

The  most  effective  method  investigated  by  the  author  is  active  stack 
fingerprinting  [10].  This  approach  is  based  on  the  observation  that  there  are  cases  where 
some  vendors  interpret  or  implement  specific  RFC  guidance  differently  from  other 
vendors  when  they  develop  their  TCP/IP  protocol  stack.  So,  by  probing  for  these 
differences  we  can  come  up  with  a  very  good  conjecture  as  to  the  exact  type  of  OS  in  use. 
As  with  the  passive  stack  fingerprinting,  these  differences  in  most  cases  are  different 
values  that  are  set  by  the  OS  in  some  of  the  fields  of  the  packets  they  send  out.  Those 
values  are  compared  with  a  database,  as  with  passive  stack  fingerprinting,  to  identify  the 
likely  implementation.  Also,  it  is  possible  to  observe  different  behavior  by  different  OSes 
in  response  to  the  same  probing  methods. 

One  might  ask  at  this  point  why  different  OSes  use  different  values  or  display 
different  behavior  if  they  conform  to  the  same  standard.  In  the  Internet,  the  format, 
syntax,  and  sequence  of  all  packets  exchanged  between  the  communicating  hosts  are 
defined  in  a  great  detail  by  the  well-known  RFCs.  However,  there  are  cases  where  these 
standards  provide  the  OS’s  vendor  with  a  degree  of  flexibility  to  use  values  for  some  of 
the  fields  in  the  headers  of  the  protocol  stack.  Further,  the  vendors  may  interpret 
differently  the  guidance  provided  from  the  RFCs  during  the  development  of  their 
protocol  stack.  Although  this  is  not  a  major  problem,  if  it  is  one  at  all,  for  the  end  systems 
to  communicate  over  the  Internet,  it  may  help  to  reveal  the  underlying  OS. 

There  are  many  methods  used  today  to  probe  for  these  differences  because  the 
more  methods  used,  the  more  differences  that  may  be  found  and  so  the  guess  would  be 
more  accurate.  Another  reason  is  because  of  security  implementations.  Administrators 
may  block  specific  types  of  packets  from  entering  their  network,  most  often  by 
establishing  a  firewall  and  configuring  it  appropriately.  Innovative,  out-of-the-box 
thinking  may  lead  to  the  creation  of  packets  that  can  circumvent  those  restrictions  and 
reach  the  intended  destination  machine. 
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B,  METHODS  OF  ACTIVE  STACK  FINGERPRINTING 

Active  stack  fingerprinting  is  based  on  the  fact  that  different  OSes  may  respond 
differently  when  they  are  triggered  in  the  same  way.  The  key  for  the  effectiveness  of  this 
teehnique  is  to  find  the  appropriate  packets  that  ean  probe  for  these  differences.  This  is  a 
process  that  demands  a  lot  of  testing  and  inspection  of  the  RFC’s  guidance  to  detect 
points  that  could  be  interpreted  differently  by  different  vendors. The  literature  deseribes 
many  methods  that  could  probe  for  those  differences.  Active  stack  fingerprinting  defines 
a  speeially  constructed  paeket  to  trigger  the  target  host  to  send  back  a  response,  whieh 
will  include  values  that  could  point  to  a  particular  OS  or  constrained  set  of  OSes.  Specific 
methods  found  in  the  literature  [10,  11]  are  described  below  and  some  of  them  are 
implemented  by  tools  available  today.  These  techniques  use  a  combination  of  TCP 
header  and  IPv4  header  field  values  to  characterize  the  target  OS. 

1,  FIN  Probe 

In  this  method,  a  FIN  paeket  is  sent  to  an  open  port.  Although  the  eommon 
response,  as  it  is  directed  by  the  RFC  793,  is  not  to  respond,  there  are  OSes  that  send  a 
response  back  with  the  FIN  and  ACK  flags  set. 

2,  Bogus  Flag  Probe 

This  method  sends  a  packet  with  the  SYN  and  an  undefined  flag  bit  set.  Some 
OSes,  sueh  as  Linux,  will  respond  with  the  flag  set  in  their  response  packet. 

3,  Initial  Sequence  Number 

This  method  sends  a  series  of  connection  request  packets  to  the  target  machine, 
and  from  the  responses  we  get  back  we  reeord  the  initial  sequence  number  (ISN)  and  we 
try  to  find  a  pattern  in  the  selection  of  the  ISN. 

4,  Don’t  Fragment  Bit  (DF) 

This  method  observes  the  responses  coming  back  from  the  target  maehine  and 
monitors  the  DF  bit  in  the  IP  header.  Some  OSes  set  this  bit  in  order  to  enhance 
performanee,  but  there  are  others  that  do  not  set  that  bit  or  set  it  only  in  specific  cases. 

5,  Initial  Window  Size 

This  method  monitors  the  initial  window  size  value  set  by  the  target  machine. 
This  value  ean  be  unique  for  some  OSes  and  thus  can  identify  the  OS. 
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6,  ACK  Value  Probe 

This  method  monitors  the  ACK  value  set  by  the  target  maehine.  There  are  cases 
where  the  value  will  be  the  sequence  number  we  sent  or  the  sequence  number  +1 . 

7,  Type  of  Service  (TOS) 

In  this  method  the  type  of  service  field  of  the  ICMP  “port  unreachable”  message 
sent  back  is  examined.  Most  OSes  use  “0”  but  this  may  vary.  There  are  cases,  for 
example  Linux,  where  they  use  OxCO. 

8,  Fragmentation  Handling 

It  is  possible  that  different  protocol  stack  implementations  handle  overlapping 
fragments  differently.  Some  OSes  will  overwrite  the  old  data  with  the  new  data,  and  vice 
versa,  when  they  reassemble  the  fragments  [12]. 

9,  TCP  Options 

Although  the  supported  TCP  options  are  defined  in  RFC  793  and  RFC  1323,  it  is 
possible  that  some  OSes  do  not  support  all  of  them.  Thus,  by  sending  a  packet  with  one 
or  more  options  set,  we  can  identify  which  options  are  supported  by  the  target  OS.  Also, 
the  supported  options  may  be  listed  in  a  different  order  in  the  response,  depending  on  the 
OS. 

10,  ICMP  Error  Message  Quenching 

RFC  1812  suggests  that  an  OS  should  limit  the  rate  at  which  it  sends  error 
messages.  This  can  be  tested  by  sending  UDP  packets  to  a  closed  port  and  then  count  the 
number  of  unreachable  messages  received  within  a  given  amount  of  time.  This  method 
has  the  disadvantage  that  some  UDP  packets  may  be  dropped  in  the  network,  making  it 
hard  to  compute  accurate  results. 

11,  ICMP  Message  Quoting 

ICMP  error  messages  should  quote  some  amount  of  information  from  the  packet 
that  generated  the  ICMP  error  message.  However,  not  all  OSes  quote  the  same  amount  of 
information.  Thus,  by  monitoring  the  amount  of  quoted  information  it  is  possible  to  make 
a  guess  about  the  OS  employed  on  the  target. 

12,  ICMP  Error  Message-Echoing  Integrity 

As  described  in  the  paragraph  above,  when  the  OS  sends  back  an  ICMP  error 
message,  it  quotes  some  amount  of  the  original  message  received.  Also,  some  stack 
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implementations  ehange  the  IP  headers  of  the  original  message.  So,  by  examining  the 
type  of  alterations  made  by  the  target,  it  is  possible  to  make  an  assumption  about  the  OS. 

This  chapter  provided  a  survey  of  methods  currently  used  to  extract  information 
either  directly  from  target  host  configurations,  such  as  port  scans,  or  from  the  packets 
generated  by  those  systems  and  sent  over  the  network.  The  latter,  referred  to  collectively 
as  stack  fingerprinting  because  of  its  extraction  of  information  from  various  protocol 
layer  headers,  may  be  either  passive  or  active.  Some  of  the  methods  introduced  here  will 
be  employed  in  a  controlled  network  environment  as  described  in  the  next  chapter 
initially  over  the  IPv4  and  then  over  IPv6. 
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III.  NETWORK  CONFIGURATION 


A.  NETWORK  SETUP 

To  identify  and  test  the  methods  of  OS  fingerprinting  used  in  a  IPv4  environment, 
we  need  to  set  up  a  small  network  lab  eonsisting  of  different  OSes.  Also,  the  same 
network  will  be  used  later  when  we  test  those  methods  in  IPv6,  thus  the  OSes  of  this 
network  should  be  eonfigured  for  dual  protoeol  staek  eapability.  This  chapter  first 
discusses  the  considerations  taken  into  account  for  selecting  the  OSes  included  in  the 
network,  then  describes  the  network  architecture,  and  finally  presents  the  packet  crafting 
process,  which  is  the  core  part  of  OS  fingerprinting. 

1,  OS  Selection 

For  the  selection  of  the  types  of  the  OSes  we  will  include  in  our  network,  we 
should  take  into  consideration  the  number  of  OSes,  the  vendor  of  the  OS,  and  the 
popularity  of  the  OS.  In  order  to  have  results  as  accurate  as  possible,  we  need  to  set  up  as 
many  OSes  as  possible.  Also,  because  the  methods  used  today  are  looking  for  differences 
in  the  protocol  stack  implemented  by  different  OSes  developed  by  different  vendors,  it 
would  by  wise  to  include  OSes  from  as  many  vendors  as  possible  in  our  selection.  And 
finally,  we  should  use  OSes  that  seem  to  have  some  level  of  popularity.  Often,  surveys 
about  the  popularity  of  the  OSes  are  conducted  .  Two  of  them  have  been  found  over  the 
Internet  and  they  present  very  interesting  information  on  this  subject.  Table  1  presents 
statistical  data  from  a  survey  conducted  by  Statemarket.com  [14]  in  a  3 -month  period 
back  in  1999.  Table  2  [15]  also  presents  statistical  data  on  the  popularity  of  OSes.  It 
covers  a  more  recent  period  of  time.  From  the  analysis  of  this  information,  we  conclude 
that  Windows  is  almost  the  dominant  OS  today.  However  we  observe  that  the  popularity 
of  others  OSes  like  Linux  and  MacOS  has  increased  during  recent  years  and  will 
probably  continue  to  increase.  However,  the  results  may  not  be  as  realistic  as  possible, 
but  the  point  is  that  the  percentage  of  popularity  for  each  of  them  is  so  distinct  among  the 
vendors  that  there  is  no  doubt  about  the  order  of  popularity. 


13 


Rank 

OS 

Avg. 

Hin.  (Date) 

Max.  (Date) 

1. 

Windows  95 

48.28% 

41.93%  (5/23/99) 

54.23%  (1/8/99) 

2. 

Windows  9B 

39.80% 

33.29%  (1/8/99) 

48.17%  (5/17/99) 

3. 

Windows  NT 

4.81% 

2.86%  (1/17/99) 

6.40%  (5/21/99) 

4. 

Macintosh 

2.72% 

2.40%  (1/17/99) 

3.04%  (1/27/99) 

5. 

WebTV 

1.81% 

1.52%  (3/17/99) 

2.23%  (1/13/99) 

6. 

Windows  3.* 

1.38% 

1.04%  (5/23/99) 

1.80%  (1/13/99) 

7. 

Other 

0.56% 

0.09%  (2/22/99) 

0.69%  (5/17/99) 

8. 

Linux 

0.20% 

0.16%  (1/9/99) 

0.22%  (5/22/99) 

9. 

SunOS 

0.16% 

0.08%  (5/10/99) 

0.23%  (2/19/99) 

10. 

Irfat 

0.04% 

0.01%  (3/2/99) 

0.06%  (2/24/99) 

Table  1.  OS  statistics  1[14] 


2006 

WinXP 

W2000 

Win98 

WinNf 

W2003 

Linux 

Mac 

June 

74.1% 

10.6% 

1.6% 

0.3% 

2.0% 

4.4% 

3.6% 

May 

74.2% 

10.7% 

1.6% 

0.2% 

2.0% 

3.4% 

3.6% 

April 

74.0% 

11.2% 

1.8% 

0.3% 

1.9% 

3.3% 

3.6% 

March 

72.9% 

11.9% 

2.0% 

0.3% 

1.8% 

3.4% 

3.5% 

February 

73.3% 

12.3% 

2.1% 

0.3% 

1.8% 

3.4% 

3.6% 

January 

72.3% 

13.1% 

2.4% 

0.3% 

1.7% 

3.3% 

3.5% 

2005 

WinXP 

W2000 

Win98 

WinNT 

W2003 

Linux 

Mac 

December 

71.6% 

13.6% 

2.6% 

0.3% 

1.7% 

3.2% 

3.3% 

November 

71.0% 

14.6% 

2.7% 

0.4% 

1.7% 

3.3% 

3.3% 

October 

70.2% 

15.0% 

2.8% 

0.4% 

1.6% 

3.3% 

3.2% 

September 

69.2% 

15.8% 

3.2% 

0.5% 

1.7% 

3.3% 

3.1% 

August 

66.3% 

17.5% 

3.2% 

0.6% 

1.7% 

3.3% 

2.9% 

July 

65.3% 

17.7% 

3.9% 

0.6% 

1.6% 

3.5% 

3.0% 

June 

64.9% 

19.1% 

3.6% 

0.7% 

1.5% 

3.5% 

3.0% 

May 

64.5% 

19.4% 

3.9% 

0.8% 

1.4% 

3.3% 

2.9% 

April 

64.0% 

19.7% 

4.1% 

0.8% 

1.4% 

3.3% 

2.9% 

March 

63.1% 

20.2% 

4.7% 

0.9% 

1.4% 

3.2% 

3.0% 

February 

62.0% 

21.1% 

5.1% 

0.9% 

1.3% 

3.2% 

2.9% 

January 

61.3% 

21.6% 

5.3% 

1.0% 

1.2% 

3.2% 

2.8% 

2004 

WinXP 

W2000 

Win98 

WinNT 

Win95 

Linux 

Mac 

December 

59.8% 

23.5% 

5.4% 

1.1% 

0.1% 

3.1% 

2.7% 

November 

59.1% 

23.7% 

5.6% 

1.2% 

0.1% 

3.1% 

2.7% 

October 

57.8% 

25.0% 

6.0% 

1.3% 

0.2% 

3.1% 

2.6% 

September 

55.9% 

26.2% 

6.4% 

1.5% 

0.2% 

3.1% 

2.6% 

August 

53.2% 

28.1% 

7.0% 

1.8% 

0.2% 

3.0% 

2.5% 

July 

52.5% 

28.4% 

7.5% 

1.9% 

0.2% 

3.1% 

2.4% 

June 

51.2% 

29.6% 

8.0% 

2.0% 

0.3% 

2.9% 

2.5% 

May 

51.0% 

29.6% 

8.2% 

2.0% 

0.3% 

2.9% 

2.5% 

April 

49.7% 

30.2% 

8.7% 

2.2% 

0.3% 

2.7% 

2.5% 

March 

48.0% 

31.1% 

9.4% 

2.4% 

0.4% 

2.6% 

2.4% 

February 

46.0% 

32.8% 

9.5% 

2.9% 

0.4% 

2.6% 

2.5% 

January 

44.1% 

33.6% 

10.4% 

3.0% 

0.4% 

2.7% 

2.4% 

2003 

WinXP 

W2000 

Win98 

WinNT 

Win95 

Linux 

Mac 

December 

43.6% 

35.2% 

10.5% 

3.4% 

0.4% 

2.7% 

2.3% 

November 

42.6% 

36.3% 

10.9% 

3.5% 

0.4% 

2.6% 

2.2% 

October 

39.4% 

37.8% 

11.5% 

4.0% 

0.5% 

2.5% 

2.1% 

September 

38.0% 

37.9% 

12.1% 

4.1% 

0.5% 

2.4% 

2.0% 

August 

36.3% 

39.9% 

12.6% 

4.6% 

0.5% 

2.4% 

2.0% 

July 

33.9% 

40.6% 

12.6% 

5.3% 

0.6% 

2.3% 

1.9% 

June 

32.8% 

40.4% 

13.4% 

5.4% 

0.6% 

2.3% 

1.8% 

May 

31.4% 

41.0% 

13.9% 

5.8% 

0.7% 

2.2% 

1.8% 

April 

30.8% 

40.9% 

14.7% 

6.0% 

0.7% 

2.1% 

1.8% 

March 

29.1% 

41.9% 

14.8% 

6.6% 

0.8% 

2.2% 

1.8% 

Table  2.  OS  statistics  2  [15] 


Taking  into  account  the  above  considerations  we  came  up  with  the  following  list  of  OSes 
for  our  network; 

•  Windows  Server  2003  Enterprise  Edition 

•  Windows  Server  2003  Standard  Edition 
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•  Windows  XP  Professional 

•  Red  Hat  Linux  Enterprise  4  WS 

•  Red  Hat  Linux  9.0 

•  Fedora  Core  4 

•  Mae  OS  X  10.4.5 

•  FreeBSD  6.0 

2.  Network  Architecture 

For  our  purposes,  the  network  eould  be  as  simple  as  possible.  The  aetual  topology 
used  for  this  thesis  is  depieted  in  Figure  2  below.  It  is  eomposed  of  one  hub,  whieh 
intereonneets  all  the  hosts  into  one  eollision  domain.  In  this  network,  there  are  four 
maehines,  in  green  eolor,  running  the  different  types  of  OSes.  The  yellow  box  represents 
the  paeket  generator,  for  whieh  we  use  a  SmartBits  6000C  deviee  manufaetured  by 
Spirent  Communications,  Inc.  The  detailed  functionalities  of  the  SmartBits  device  and  its 
setup  for  this  thesis  will  be  presented  in  the  next  section.  The  laptop  above  the  “Smart 
Bits  Chassis  is  necessary  for  controlling  the  packet  generator.  Finally,  the  packet  analyzer 
is  represented  in  blue.  This  is  a  simple  PC,  which  runs  a  packet  analyzer  like  Wireshark 
to  capture  the  packets  exchanged  across  the  network. 

Initially,  the  OSes  were  installed  on  the  machines  of  the  network,  which  is  a 
challenging  and  time  consuming  process  because  of  the  multi-boot  configuration.  Next, 
each  network  module  on  every  OS  needs  to  be  configured  for  dual  stack  network 
connectivity.  This  is  necessary  because  we  need  to  test  the  OS  detection  process  first  on 
IPv4  and  later  on  IPv6.  Finally,  the  SmartBits  chassis  is  connected  to  the  network  and  the 
“controller”  and  configured  for  its  connectivity. 
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Figure  2.  Network  architeeture. 


B.  PACKET  CRAFTING 

Central  to  the  eoncept  of  OS  fingerprinting  is  the  generation  of  various  paekets 
that  will  trigger  the  remote  host  to  respond  in  a  way  that  will  reveal  some  unique 
eharaeteristies  of  the  underlying  OS.  Any  OS  with  a  network  module  in  its  arehiteeture 
supports  the  generation  of  paekets  that  enable  the  applieations  running  on  top  of  it  to 
eommunicate  over  the  Internet.  Those  paekets  are,  in  most  of  the  cases,  ordinary  packets 
exchanged  across  the  network  and  are  responsible  for  making  the  communication  among 
the  applications  feasible.  For  OS  detection,  however,  those  types  of  packets  may  not  be 
sufficient  to  make  an  accurate  guess  about  the  OS  type.  Here  is  where  packet  crafting 
may  help  to  circumvent  any  of  those  restrictions.  Packet  crafting  uses  the  same  network 
protocol  stack  as  any  other  application  but  gives  the  user  the  ability  to  form  any  kind  of 
packet  desired  and  send  it  to  another  host  connected  to  the  network. 
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Many  tools  are  available  today  for  paeket  crafting.  Those  tools  normally  support 
two  modes  of  operation.  One  mode  provides  the  user  the  ability  to  select  the  type  of 
packet  to  be  sent  from  a  limited  number  of  supported  protocols,  and  the  other  mode  gives 
the  user  the  opportunity  to  create  a  packet  by  inserting  the  values  of  his  choice  in 
hexadecimal  format  and  actually  create  a  complete  frame  from  the  bottom  up. 

The  last  mode  of  operation,  although  it  is  very  powerful,  has  the  disadvantage  that 
the  user  must  be  aware  of  the  details  of  the  protocols  that  he  is  about  to  use.  This  is 
because  a  single  incorrect  value  may  cause  the  packet  to  be  interpreted  as  corrupted  from 
the  receiver  and  finally  dropped  without  further  notice  to  the  sender.  Also,  it  is  very  time 
consuming  because  all  values,  even  the  default,  must  be  inserted  manually  and  in  the 
correct  order.  Finally,  the  calculation  of  the  checksum,  which  is  used  by  various 
protocols,  must  be  accomplished.  In  this  case,  the  user  must  calculate  the  checksum 
manually  and  then  insert  that  value  where  ever  is  applicable. 

1.  SmartBits  Overview 

SmartBits  is  a  tool  that  supports  packet  crafting,  along  with  many  more  services, 
and  was  selected  for  use  for  this  thesis.  It  is  a  performance  analysis  system  that  allows  the 
user  to  test,  simulate,  analyze,  troubleshoot,  develop,  and  certify  equipment  such  as 
routers,  repeaters,  bridges,  and  network  interface  cards  (NICs),  as  well  as  VLANs, 
ELANs,  and  live  networks.  It  is  composed  of  the  SmartBits  hardware,  shown  in  Figure  3 
below,  and  the  SmartBits  software. 
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Figure  3.  SmartBits  chassis  family. 


Each  chassis  supports  a  number  of  SmartCards/modules,  which  are  actually 
configurable  network  cards.  Each  module  is  connected  to  the  network  under  test  and  is 
the  interface  for  sending  or  receiving  packets. 

Any  SmartsBits  system  supports  a  variety  of  software  applications.  Each 
application  runs  on  PCs  or  workstations  connected  to  the  SmartBits  chassis.  Almost  all 
SmartBits  applications  have  an  easy-to-use  Graphical  User  Interface  (GUI),  together  with 
test  setup  wizards  and  shortcut  options,  which  greatly  simplify  the  test  setup  procedure. 
Test  results  can  be  viewed  in  spreadsheet  or  graph  form,  providing  complete  results 
analysis  support. 
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2,  Smartwindow  Transmit  Setup 

The  application  that  provides  the  ability  to  send  specially  formatted  packets  is  the 
Smartwindow.  The  process  is  almost  simple  because  of  the  graphical  interface.  First,  the 
SmartBits  module  must  be  connected  to  the  network  and  the  SmartBits  chassis  connected 
to  the  PC  with  the  Smartwindow  application  installed.  The  GUI  for  Smartwindow  is 
shown  in  Figure  4.  This  picture  reflects  the  SmartBits  chassis  used.  The  chassis  used  in 
this  case  is  the  SmartBits  6000C,  which  supports  two  modules  of  which  only  one  is 
needed  in  our  case. 


Figure  4.  Smartwindow  application  interface. 
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For  each  module  we  can  select  the  “transmit  setup”  wizard  shown  in  Figure  5,  and 
use  a  graphical  interface  to  select  the  desired  protocol  to  be  included  and  set  the  values 
for  most  of  their  fields  for  each  one  of  them.  In  Figures  6,  7,  and  8  below  are  presented 
the  different  interfaces  for  the  general,  or  basic,  settings  for  the  TCP,  IPv6,  and  Ethernet 
protocol  headers. 


Figure  5.  Transmit  setup  for  General  configuration. 

In  the  general  configuration,  we  set  the  size  of  the  entire  frame  to  be  sent  and  also 
some  predefined  error  generation  and  security  features,  available  for  use  if  necessary. 
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At  the  TCP  header  interfaee  we  ean  eonfigure  the  following  values,  whieh  are 
represented  in  the  window  interface  with  a  white  background; 

•  Source  and  destination  port  numbers 

•  Window  size 

•  Initial  sequence  number 

•  Acknowledgment  number 

•  Urgent  pointer 

•  TCP  flags  set 

The  values  that  have  a  shaded  background  can  not  be  changed.  Also,  in  this  mode 
we  cannot  set  any  options  available  at  the  TCP  header  and  the  two  reserved  flags,  ECN 
and  CWR.  This  is  actually  one  restriction  of  this  mode  of  operation. 


Figure  6.  Transmit  setup  for  TCP  header  configuration. 
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At  the  IPv6  header  interface  we  can  configure  the  following  values,  which  are 
represented  with  a  white  background; 

•  Source  and  destination  address 

•  Flow  label 

•  Traffic  class 

•  Hop  limit 


Figure  7.  Transmit  setup  for  IPv6  header  configuration. 

The  other  fields  of  the  IPv6  header  cannot  be  changed.  Also,  we  can  choose  the 
“Enable  Extension  Header”  option,  in  case  we  need  to  include  any  extension  headers. 
These  headers  include  the  following: 

•  Hop-by-hop  options 

•  Destination  options 

•  Routing  option 

•  Eragment 
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•  Authentication 


•  Encapsulation  security  payload 

It  is  possible  for  the  user  to  select  one  or  more  of  them  to  be  included  in  the  order  he 
wishes. 

At  the  Ethernet  interface,  shown  in  Eigure  9,  we  can  configure  the  source  and 
destination  MAC  address.  The  type  field  of  the  TCP  header  is  configured  automatically 
by  the  application. 


Eigure  8.  Transmit  setup  for  Ethernet  configuration. 

Similarly,  other  protocol  headers  instead  of  those  described  earlier  can  be 
configured.  Those  include  the  UDP  and  IPv4  headers.  Further,  we  could  select  the  option 
to  send  a  packet  without  any  transport  layer  headers. 

The  other  available  mode  of  operation  is  one  where  the  user  constructs  the  entire 
frame  to  be  sent.  This  mode  is  more  appropriate  when  we  need  to  include  some  TCP 
options  in  the  packet.  In  this  mode,  the  user  must  input  the  appropriate  values  for  each 
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header  in  hexadeeimal  format  and  calculate  the  checksum  value  manually.  Figure  9 
shows  the  “transmit  setup”  wizard  for  this  mode  of  operation.  In  this  mode,  the  user  can 
chose  the  number  of  packets  to  be  sent,  the  length  of  the  packet,  and  any  application  layer 
data  to  be  included.  More  options  are  supported  in  this  wizard  but  are  irrelevant  for  our 
case. 


Figure  9.  Transmit  setup  for  editing  the  entire  packet  manually. 


Figure  10.  SmartWindow  application  interface. 
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The  next  step  is  to  edit  the  packet,  like  the  one  presented  in  Figure  10.  The 
following  values,  in  hexadecimal,  have  been  set  for  this  packet. 

•  Destination  MAC  address  :  00123FAE2159 

•  Source  MAC  address  ;  00123FADE2F5 

•  Type  code  :  86DD 

•  Version  :  6  (IPv6  header) 

•  Traffic  class  ;  00 

•  Elow  lebel  ;  00000 

•  Payload  length  ;  0028  (40  Bytes) 

•  Next  header  ;06  (TCP) 

•  Hop  limit  :40  (64  hops) 

•  Source  IPv6  address  :  20000000000000040000000000000009 

•  Destination  IPv6  address  :  20000000000000040000000000000005 

•  Source  port  number  ;  AAAB  (decimal  43691) 

•  Destination  port  number  ;  0016  (decimal  22) 

•  Sequence  number  :  AAAAAAAA 

•  Acknowledgment  number  :  00000000 

•  Header  length  :  A  (10  32-bit  words) 

•  Reserved  :  0 

•  Elags  :  42  (ECN,  SYN) 

•  Window  size  :  0800 

•  Checksum  :  8DB6 

•  Urgent  pointer  ;  0000 

•  Maximum  segment  size  ;  020405 AO  (1440) 


25 


•  SACK  permitted 

•  Time  stamp  tsval ,  tsecr 

•  NOP 

•  Window  scale 


:  0402 

:  080A05376CB700000000 
;  01 

:  03030A(10) 


One  difficulty  we  encountered  with  this  mode  of  operation  is  the  calculation  of 
the  checksum  value.  If  the  checksum  is  not  correct,  the  destination  will  drop  the  packet 
without  any  notice  to  the  source  of  the  packet.  There  are  some  scripts  available  that  can 
calculate  the  checksum,  but  in  this  case  also  the  user  has  to  provide  the  necessary  fields 
included  in  the  pseudo  header  and  used  for  the  checksum  calculation  one  by  one.  After 
some  experimentation,  we  discovered  a  simple  work-around  to  find  the  correct  value  of 
the  checksum  very  quickly.  It  has  been  described  earlier  that  the  OS  fingerprinting 
process  and  is  performed  with  the  help  of  a  packet  analyzer.  For  this  thesis,  we  used 
Wireshark.  When  a  packet  with  an  incorrect  checksum  value  is  sent  through  our  network 
it  will  be  received  at  the  destination  host  and  the  packet  analyzer.  While  destination  will 
drop  the  packet,  Wireshark  will  capture  the  packet  and  present  the  values.  Wireshark  will 
identify  the  wrong  checksum  and  will  make  a  notice  that  the  checksum  was  incorrect  and 
will  include  the  correct  value  of  the  checksum  for  this  packet.  So,  we  can  just  send  the 
packet  once  with  an  arbitrary  value  for  the  checksum  and  after  we  record  the  correct 
value,  calculated  by  Wireshark,  we  simply  apply  the  correction  and  resend  the  packet. 

With  the  test  bed  network  established  and  the  means  to  generate  arbitrary  packets 
identified,  we  are  ready  to  employ  and  assess  the  various  means  of  extracting  identifying 
characteristics  of  operating  systems.  We  begin  in  the  next  chapter  by  looking  at  the 
results  of  two  of  these  tools  as  applied  to  IPv4  and  IPv6. 
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IV.  TESTING  OF  EXISTING  IPV4-BASED  METHODS 


A.  INTRODUCTION 

Many  methods  have  been  developed  to  perform  OS  fingerprinting  in  an  IPv4 
environment.  Two  of  the  tools  that  have  the  eapability  to  conduet  OS  deteetion  are  Nmap 
and  Queso.  This  ehapter  initially  deseribes  the  methods  used  by  these  two  tools  and 
validates  them  against  the  OSes  running  on  the  maehines  of  the  network  presented  in 
Figure  2.  Then  follows  a  diseussion  about  the  most  important  differenees  between  the 
IPv4  and  the  IPv6  headers  and  finally,  the  methods  deseribed  earlier  applied  in  IPv6 
environment. 

1.  OS  Detection  by  Nmap 

Nmap  was  originally  developed  for  port  seanning,  but  later  the  eapability  for  OS 
deteetion  was  added.  Nmap,  performs  a  3-step  proeedure  for  OS  deteetion.  Initially  it 
attempts  to  determine  if  the  target  host  is  “alive,”  that  is,  if  it  has  network  eonneetivity. 
The  next  step  is  to  port  sean  the  target  host.  This  step  triggers  the  ports  on  the  target  and 
determines  whieh  of  them  are  open  or  elosed.  Nmap  needs  at  least  one  open  and  one 
elosed  port  in  order  to  make  an  aecurate  guess  about  the  OS  running  on  the  target  host. 
This  proeess  yielded  the  results  presented  in  Table  3  below  regarding  the  listening  TCP 
ports  on  each  OS  in  the  network  of  Figure  2: 
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22 

111 

135 

139 

445 

1025 

3689 

32768 

32769 

MS  Server  2003  Enter.  Ed. 

V 

V 

V 

V 

MS  Server  2003  Stand.  Ed. 

V 

V 

V 

Windows  XP  Professional 

V 

V 

V 

Red  Hat  Linux  Enter.  4  WS 

V 

V 

a/ 

Red  Hat  Linux  9.0 

V 

V 

a/ 

Eedora  cored 

V 

V 

a/ 

EreeBSD  6.0 

Mac  OS  X 

a/ 

Table  3.  Open  TCP  ports  on  each  OS  with  IPv4  address. 


The  FreeBSD  6.0  had  no  ports  open  by  default,  thus  we  have  to  open  at  least  one 
manually  in  order  to  be  able  to  trigger  it  later  for  OS  detection.  Also,  Nmap  is  not  able  to 
conduct  OS  fingerprinting  in  IPv6,  but  it  can  port  scan  a  host  by  using  its  IPv6  address. 
The  results  from  port  scanning  the  machines  using  IPv6  are  presented  in  Table  4  below. 
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22 

135 

445 

1025 

MS  Server  2003  Enter.  Ed. 

V 

V 

V 

MS  Server  2003  Stand.  Ed. 

V 

Windows  XP  Professional 

V 

Red  Hat  Linux  Enter.  4  WS 

V 

Red  Hat  Linux  9.0 

V 

Eedora  cored 

V 

EreeBSD  6.0 

Mac  OS  X 

able  4. 


Open  TCP  ports  on  eaeh  OS  with  IPv6  address 


From  this  table  it  is  evident  that  the  same  services  are  not  necessarily  available 
with  both  IPv4  and  IPv6,  at  least  by  default.  In  this  case  also,  FreeBSD  6.0  and  the  Mac 
OS  X  didn’t  have  any  open  ports,  thus  we  need  to  open  at  least  one  manually  for  both. 

Finally,  after  the  open  ports  have  been  found,  Nmap  sends  a  series  of  specially 
formatted  TCP  and  UDP  packets  and  then  examines  the  responses  from  the  target 
machine.  Nmap  examines  the  fields  in  the  headers  of  the  responses  and  compares  them 
against  a  database  of  known  fingerprints^.  If  there  is  a  match  it  will  come  up  with  an 
inference  about  the  OS  running  on  the  target  machine.  More  information  about  the 
capabilities  of  Nmap  can  be  found  at  www.insecure.org/nmap/data/nmap_manpage.html. 

2,  OS  Detection  By  Queso 

Queso  is  another  tool  for  OS  detection  in  an  IPv4  environment.  However,  it  is 
much  simpler  than  Nmap.  This  program  makes  the  assumption  that  we  already  know  at 
least  one  open  port  on  the  target  machine,  so  we  have  just  to  specify  the  IP  address  and 
the  open  port.  Queso  uses  seven  methods  to  detect  the  OS.  That  means  seven  packets. 


^  There  are  about  1,500  fingerprints  in  the  database 
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formatted  appropriately,  are  sent  to  the  target.  Then  some  of  the  values  in  the  headers  of 
the  responses  are  examined  against  a  list  of  known  fingerprints,  as  is  the  ease  with  Nmap, 
and  if  there  is  a  match,  it  will  come  up  with  a  guess  about  the  OS  running  on  the  target. 


B,  VALIDATION  IN  IPV4  ENVIRONMENT 

Now  that  we  have  seen  the  general  view  of  how  those  tools  perform  the  OS 
fingerprinting  we  can  test  them  against  the  machines  of  our  network  and  develop  a  solid 
baseline  for  OS  fingerprinting  in  IPv4. 

1.  Test  Cases  by  Nmap 

The  methods  utilized  by  Nmap  are  described  below  and  the  results  for  each  one  of 
them  gathered  for  each  OS  are  presented  in  the  following  Tables. 

a.  Test  case  1,  SYN,  ECN packet  with  options  to  an  open  port 

This  method  sends  a  packet  with  the  SYN  and  ECN  bits  set  and  some 
options  included  in  the  TCP  header.  This  packet  is  a  request  for  setting  up  a  connection 
with  the  remote  host  on  the  port  number  specified  in  the  port  number  field  of  the  packet 
send.  The  common  behavior  of  the  host,  which  has  the  port  listening  for  incoming 
connections,  is  to  acknowledge  the  request  and  respond  with  a  packet  with  the  SYN  and 
ACK  flag  bits  set.  A  summary  of  the  packet  sent  to  each  host  in  the  network  and  the 
responses  received  from  them  is  presented  in  Table  5. 

b.  Test  case  2,  NULL  packet  with  options  to  an  open  port 

This  method  sends  a  packet  with  no  flags  set  and  some  options  included  in 
the  TCP  header.  A  summary  of  the  packet  sent  to  each  host  in  the  network  and  the 
responses  received  from  them  is  presented  in  Table  6. 

c.  Test  case  3,  FLN,  SYN,  PSH,  URG  packet  with  options  to  an 
open  port 

This  method  sends  a  packet  with  the  FIN,  SYN,  PSH,  and  URG  bits  set 
and  some  options  included  in  the  TCP  header.  A  summary  of  the  packet  sent  to  each  host 
in  the  network  and  the  responses  received  from  them  is  presented  in  Table  7. 

d.  Test  case  4,  ACK  packet  with  options  to  an  open  port 

This  method  sends  a  packet  with  the  ACK  flag  set  and  some  options 
included  in  the  TCP  header.  This  packet  originally  acknowledges  a  packet  sent  from  the 
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remote  host.  Since  no  packet  was  sent  earlier  from  that  host,  the  common  response  is  for 
the  target  host  to  send  back  a  packet  with  the  reset  (RST)  flag  set.  A  summary  of  the 
packet  sent  to  each  host  in  the  network  and  the  responses  received  from  them  is  presented 
in  Table  8. 

e.  Test  case  5,  SYN  packet  with  options  to  a  closed  port 

This  method  sends  a  packet  with  the  SYN  flag  set  and  some  options 
included  in  the  TCP  header  to  a  closed  port.  This  is  a  request  to  establish  a  connection 
with  the  remote  host  on  the  specified  port  number.  Because  the  port  is  closed,  the  remote 
host  must  reject  the  request  and  send  back  a  packet  with  the  RST  and  ACK  flags  set.  A 
summary  of  the  packet  sent  to  each  host  in  the  network  and  the  responses  received  from 
them  is  presented  in  Table  9. 

f.  Test  case  6,  ACK  packet  with  options  to  a  closed  port 

This  method  sends  a  packet  with  the  ACK  flag  set  and  some  options 
included  in  the  TCP  header  to  a  closed  port.  The  ACK  flag  indicates  that  the  sender 
acknowledges  some  data  sent  from  the  remote  host.  In  this  case,  however,  the  remote 
host  has  neither  sent  any  data  nor  is  even  listening  to  the  port  for  incoming  packets.  Thus, 
the  remote  host  sends  back  a  packet  with  the  RST  flag  set.  A  summary  of  the  packet  sent 
to  each  host  in  the  network  and  the  responses  received  from  them  is  presented  in  Table 
10. 

g.  Test  case  7,  FIN,  PSH,  URG  packet  with  options  to  a  closed  port 

This  method  sends  a  packet  with  the  FIN,  PSH,  and  URG  flags  set  and 

some  options  included  in  the  TCP  header  to  a  closed  port.  The  FIN  flag  in  the  header 
indicates  that  the  sender  is  attempting  to  close  a  connection,  but  because  there  is  not  any 
active  connection,  the  remote  host  sends  back  a  packet  with  the  RST  and  ACK  flags  set. 
A  summary  of  the  packet  sent  to  each  host  in  the  network  and  the  responses  received 
from  them  is  presented  in  Table  1 1 . 

h.  Test  case  8,  UDP  packet  with  data  to  a  closed  port 

This  method  sends  a  UDP  packet  to  a  closed  port.  The  common  response 
is  for  the  remote  host  to  send  back  an  ICMP  port  unreachable  packet  (type  3,  code  3).  A 
summary  of  the  packet  sent  to  each  host  in  the  network  and  the  responses  received  from 
them  is  presented  in  Table  12. 
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Test  Case  1-Nmap 

SYN,  ECN  packet  with  options  to  an  open  port 


Packet  send 


HEADER  LENGTH 

20 

TOS 

0 

IPV4 

TOTAL  LENGTH 

60 

FLAGS 

0 

SEQUENCE 

SEQ5 

ACKNOWLEDGE 

0 

HEADER 

40 

TCP 

FLAGS 

SYN,  ECN 

OPTIONS 

window  scale  :  10 

NOP 

max  seg  size  :  265 
time  stamp  :  X,  0 

EOL 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP  2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

HEADER  LENGTH 

20 

20 

20 

20 

20 

20 

20 

20 

TOS 

0 

0 

0 

0 

0 

0 

0 

0 

IPV4 

TOTAL  LENGTH 

60 

60 

60 

60 

60 

60 

60 

60 

FLAGS 

0 

0 

DF 

DF 

DF 

DF 

DF 

DF 

TTL 

128 

128 

128 

64 

64 

64 

64 

64 

SEQUENCE 

ISN® 

ISN 

ISN 

ISN 

ISN 

ISN 

ISN 

ISN 

ACKNOWLEDGE 

SEQ++7 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

FLAGS 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

TCP 

HEADER 

40 

40 

40 

40 

40 

40 

40 

40 

WINDOW  SIZE 

16384 

16384 

16430/655358 

5792 

5792 

5792 

65535 

65535 

OPTIONS 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

window  scale  :  0(xl) 

window  scale  :  0(xl) 

window  scale  :  0(xl) 

NOP 

NOP 

NOP 

window  scale  :  l(x2) 

window  scale  :  0(xl) 

NOP 

NOP 

NOP 

Time  stamp  :  X,  Y^ 

Time  stamp  :  X,  Y 

Time  stamp  :  X,  Y 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

Time  stamp  :  0,  0 

Time  stamp  :  0,  0 

Time  stamp  :  0,  0 

window  scale  :  2(x4) 

window  scale  :  2(x4) 

window  scale  :  0(xl) 

Time  stamp  X,  Y 

Time  stamp  X,  Y 

Table  5.  Test  case  1  by  Nmap,  SYN,  ECN  packet  with  options  to  an  open  port 


^  A  randomly  selected  Initial  Sequence  number 
®  The  value  is  selected  from  the  OS 
^  The  next  expected  sequence  number 

^  It  has  been  observed  that  Windows  XP  Pro  may  use  either  values  for  their  Window  Size 
9  X,  Y  are  tsval  and  tsecr  values  that  change  over  time  and  set  by  the  OS 
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Test  Case  2-  Nmap 

NULL  packet  with  options  to  an  open  port 


Packet  send 


HEADER  LENGTH 

20 

TOS 

0 

IPV4 

TOTAL  LENGTH 

60 

FLAGS 

0 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

HEADER 

40 

TCP 

FLAGS 

0 

OPTIONS 

window  scale  :  10 

NOP 

max  seg  size  :  265 

Time  stamp  :  X,  0 

EOL 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

HEADER  LENGTH 

20 

20 

20 

TOS 

0 

0 

0 

IPV4 

TOTAL  LENGTH 

40 

40 

40 

FLAGS 

0 

0 

0 

NO  REPLY 

NO  REPLY 

NO  REPLY 

NO  REPLY 

NO  REPLY 

TTL 

128 

128 

128 

SEQUENCE 

0 

0 

0 

ACKNOWLEDGE 

SEQ 

SEQ 

SEQ 

HEADER 

20 

20 

20 

TCP 

FLAGS 

RST,  ACK 

RST,  ACK 

RST,  ACK 

WINDOW  SIZE 

0 

0 

0 

OPTIONS 

-- 

-- 

-- 

Table  6. 


Test  ease  2  by  Nmap,  NULL  packet  with  options  to  an  open  port 


33 


Test  Case  3-  Nmap 

FIN,  SYN,  PSH,  URG  packet  with  options  to  an  open  port 


Packet  send 


HEADER  LENGTH 

20 

TOS 

0 

IPV4 

TOTAL  LENGTH 

60 

FLAGS 

0 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

HEADER 

40 

TCP 

FLAGS 

FIN,  SYN,  PSH,  URG 

OPTIONS 

window  scale  :  10 

NOP 

max  seg  size  :  265 

Time  stamp  :  X,  0 

EOL 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

HEADER  LENGTH 

TOS 

0 

0 

0 

0 

0 

0 

0 

IPV4 

TOTAL  LENGTH 

40 

40 

40 

40 

40 

40 

40 

NO  REPLY 

FLAGS 

0 

0 

DF 

DF 

DF 

DF 

DF 

TTL 

128 

128 

128 

64 

64 

64 

64 

SEQUENCE 

ISN 

ISN 

ISN 

ISN 

ISN 

ISN 

ISN 

ACKNOWLEDGE 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

HEADER 

40 

40 

40 

40 

40 

40 

40 

TCP 

FLAGS 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

WINDOW  SIZE 

16384 

16384 

16430/65535 

5792 

5792 

5792 

65535 

OPTIONS 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

Win  scale  :  0(xl) 

Win  scale  :  0(xl) 

Win  scale  :  0(xl) 

NOP 

NOP 

NOP 

Win  scale  :  l(x2) 

NOP 

NOP 

NOP 

Time  stamp  :  X,  Y 

Time  stamp  :  X,  Y 

Time  stamp  :  X,  Y 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

Time  stamp  :  0,  0 

Time  stamp  :  0,  0 

Time  stamp  :  0,  0 

Win  scale  :  2(x4) 

Win  scale  :  2(x4) 

Win  scale  :  0(xl) 

Time  stamp  :  X,  Y 

Table  7.  Test  ease  3  by  Nmap,  FIN,  SYN,  PSH,  URG  paeket  with  options  to  an  open  port 


34 


Test  Case  4-  Nmap 


ACK  packet  with  options  to  an  open  port 


Packet  send 


HEADER  LENGTH 

20 

TOS 

0 

IPV4 

TOTAL  LENGTH 

60 

FLAGS 

0 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

HEADER 

40 

TCP 

FLAGS 

ACK 

OPTIONS 

window  scale  :  10 

NOP 

max  seg  size  :  265 

Time  stamp  :  X,  0 

EOL 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

HEADER  LENGTH 

20 

20 

20 

20 

20 

20 

20 

20 

TOS 

0 

0 

0 

0 

0 

0 

0 

0 

IPV4 

TOTAL  LENGTH 

40 

40 

40 

40 

40 

40 

40 

40 

FLAGS 

0 

0 

0 

DF 

DF 

DF 

DF 

0 

TTL 

128 

128 

128 

64 

64 

64 

64 

64 

SEQUENCE 

0 

0 

0 

0 

0 

0 

0 

0 

ACKNOWLEDGE 

0 

0 

0 

0 

0 

0 

0 

0 

HEADER 

20 

20 

20 

20 

20 

20 

20 

20 

TCP 

FLAGS 

RST 

RST 

RST 

RST 

RST 

RST 

RST 

RST 

WINDOW  SIZE 

0 

0 

0 

0 

0 

0 

0 

0 

OPTIONS 

-- 

-- 

-- 

-- 

-- 

-- 

-- 

Table  8.  Test  ease  4  by  Nmap,  ACK  packet  with  options  to  an  open  port 
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Test  Case  5-  Nmap 


SYN  packet  with  options  to  a  closed  port 


Packet  send 


HEADER  LENGTH 

20 

TOS 

0 

IPV4 

TOTAL  LENGTH 

60 

FLAGS 

0 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

HEADER 

40 

TCP 

FLAGS 

SYN 

OPTIONS 

window  scale  :  10 

NOP 

max  seg  size  :  265 

Time  stamp  :  X,  0 

EOL 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

HEADER  LENGTH 

20 

20 

20 

20 

20 

20 

20 

20 

TOS 

0 

0 

0 

0 

0 

0 

0 

0 

IPV4 

TOTAL  LENGTH 

40 

40 

40 

40 

40 

40 

40 

40 

FLAGS 

0 

0 

0 

DF 

DF 

DF 

DF 

0 

TTL 

128 

128 

128 

64 

64 

64 

64 

64 

SEQUENCE 

0 

0 

0 

0 

0 

0 

0 

0 

ACKNOWLEDGE 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

HEADER 

20 

20 

20 

20 

20 

20 

20 

20 

TCP 

FLAGS 

RST,  ACK 

RST,  ACK 

RST,  ACK 

RST,  ACK 

RST,  ACK 

RST,  ACK 

RST,  ACK 

RST,  ACK 

WINDOW  SIZE 

0 

0 

0 

0 

0 

0 

0 

0 

OPTIONS 

-- 

-- 

-- 

-- 

-- 

-- 

-- 

Table  9.  Test  case  5  by  Nmap,  SYN  packet  with  options  to  a  closed  port 
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Test  Case  6-  Nmap 

ACK  packet  with  options  to  a  closed  port 

Packet  send 


HEADER  LENGTH 

20 

TOS 

0 

IPV4 

TOTAL  LENGTH 

60 

FLAGS 

0 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

HEADER 

40 

TCP 

FLAGS 

ACK 

OPTIONS 

window  scale  :  10 

NOP 

max  seg  size  :  265 
Time  stamp  :  X,  0 

EOL 

Packet  received 

Windows  Server  2003 
Enterprise  Edition 

SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP2 

Red  Hat  Enterprise 

Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

HEADER  LENGTH 

20 

20 

20 

20 

20 

20 

20 

20 

TOS 

0 

0 

0 

0 

0 

0 

0 

0 

IPV4 

TOTAL  LENGTH 

40 

40 

40 

40 

40 

40 

40 

40 

FLAGS 

0 

0 

0 

DF 

DF 

DF 

DF 

0 

TTL 

128 

128 

128 

64 

64 

64 

64 

64 

SEQUENCE 

0 

0 

0 

0 

0 

0 

0 

0 

ACKNOWLEDGE 

0 

0 

0 

0 

0 

0 

0 

0 

HEADER 

20 

20 

20 

20 

20 

20 

20 

20 

TCP 

FLAGS 

RST 

RST 

RST 

RST 

RST 

RST 

RST 

RST 

WINDOW  SIZE 

0 

0 

0 

0 

0 

0 

0 

0 

OPTIONS 

— 

— 

— 

— 

— 

— 

— 

Table  10.  Test  ease  6  by  Nmap,  ACK  paeket  with  options  to  a  elosed  port 
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Test  Case  7-  Nmap 


FIN,  PSH,  URG  packet  to  a  closed  port 


Packet  send 


HEADER  LENGTH 

20 

TOS 

0 

IPV4 

TOTAL  LENGTH 

60 

FLAGS 

0 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

HEADER 

40 

TCP 

FLAGS 

FIN,  PSH,  URG 

OPTIONS 

window  scale  :  10 

NOP 

max  seg  size  :  265 
Time  stamp  :  X,  0 

EOL 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

HEADER  LENGTH 

20 

20 

20 

20 

20 

20 

20 

20 

TOS 

0 

0 

0 

0 

0 

0 

0 

0 

IPV4 

TOTAL  LENGTH 

40 

40 

40 

40 

40 

40 

40 

40 

FLAGS 

0 

0 

0 

DF 

DF 

DF 

DF 

0 

TTL 

128 

128 

128 

64 

64 

64 

64 

64 

SEQUENCE 

0 

0 

0 

0 

0 

0 

0 

0 

ACKNOWLEDGE 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ 

SEQ 

HEADER 

20 

20 

20 

20 

20 

20 

20 

20 

TCP 

FLAGS 

RST,  ACK 

RST,  ACK 

RST,  ACK 

RST,  ACK 

RST,  ACK 

RST,  ACK 

RST,  ACK 

RST,  ACK 

WINDOW  SIZE 

0 

0 

0 

0 

0 

0 

0 

0 

OPTIONS 

— 

— 

— 

— 

— 

— 

— 

Table  1 1 .  Test  ease  7  by  Nmap,  FIN,  PSH,  URG  paeket  with  options  to  a  elosed  port 
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Test  Case  8-  Nmap 

UDP  packet  with  data  to  a  closed  port 


Packet  send 


HEADER  LENGTH 

20 

TOS 

0 

IPV4 

TOTAL  LENGTH 

328 

FLAGS 

0 

DATA 

300  Bytes 

UDP 

LENGTH 

308 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

HEADER  LENGTH 

20 

20 

20 

20 

20 

20 

20 

20 

TOS 

0 

0 

0 

1100  00  0  0 

1100  00  0  0 

1100  00  0  0 

0 

0 

IPV4 

TOTAL  LENGTH 

176 

176 

176 

356 

356 

356 

56 

56 

FLAGS 

0 

0 

0 

0 

0 

0 

0 

0 

TTL 

128 

128 

128 

64 

64 

64 

64 

64 

TYPE 

3 

3 

3 

3 

3 

3 

3 

3 

ICMP 

CODE 

3 

3 

3 

3 

3 

3 

3 

3 

DATA 

120  Bytes 

120  Bytes 

120  Bytes 

300  Bytes 

300  Bytes 

300  Bytes 

NO  DATA 

NO  DATA 

Table  12.  Test  ease  8  by  Nmap,  UDP  paeket  with  data  to  a  elosed  port 
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2,  Test  Cases  By  Queso 

The  methods  implemented  by  Queso  are  deseribed  below  and  the  results  from 
using  Queso  against  the  OSes  running  in  the  network  of  Figure  2  are  presented  in  the 
following  Tables. 

a.  Test  case  1,  SYN packet  without  options  to  an  open  port 

In  this  method,  a  eommon  request  for  setting  up  a  eonneetion'^’  with  the 
target  host  on  the  speeified  port  number  is  sent  to  that  machine.  The  common  action  for  a 
machine  that  listens  for  incoming  requests  is  to  accept  the  request  and  respond  with  a 
SYN/ACK  packet.  A  summary  of  the  packet  sent  to  each  host  in  the  network  and  the 
responses  received  from  them  is  presented  in  Table  13. 

b.  Test  case  2,  SYN,  ACK packet  without  options  to  an  open  port 

In  this  method,  a  packet  is  sent  that  actually  accepts  an  incoming  request 
to  set  up  a  connection.  Because  no  request  has  been  sent  from  the  remote  machine,  that 
machine  will  send  back  a  RST  packet.  A  summary  of  the  packet  sent  to  each  host  in  the 
network  and  the  responses  received  from  them  is  presented  in  Table  14. 

c.  Test  case  3,  FIN  packet  without  options  to  an  open  port 

In  this  method,  a  packet  is  sent  with  the  FIN  flag  set.  In  this  case,  the  way 
the  remote  machines  respond  may  vary.  A  summary  of  the  packet  sent  to  each  host  in  the 
network  and  the  responses  received  from  them  is  presented  in  Table  15. 

d.  Test  case  4,  FIN,  ACK  packet  without  options  to  an  open  port 

In  this  method,  a  packet  is  sent  with  the  FIN  and  ACK  flags  set.  A 
summary  of  the  packet  sent  to  each  host  in  the  network  and  the  responses  received  from 
them  is  presented  in  Table  16. 

e.  Test  case  5,  SYN,  FIN  packet  without  options  to  an  open  port 

In  this  method,  a  packet  is  sent  with  the  SYN  and  FIN  flags  set.  A 
summary  of  the  packet  sent  to  each  host  in  the  network  and  the  responses  received  from 
them  is  presented  in  Table  17. 


This  is  the  first  part  of  the  3-way  handshake  between  client  and  server 
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f.  Test  case  6,  PSH packet  without  options  to  an  open  port 

In  this  method,  a  packet  is  sent  with  the  PSH  flag  set.  A  summary  of  the 
packet  sent  to  each  host  in  the  network  and  the  responses  received  from  them  is  presented 
in  Table  18. 

g.  Test  case  7,  SYN,  ECN,  CWR  packet  without  options  to  an  open 
port 

In  this  method,  a  packet  is  sent  with  the  SYN  flag  and  two  more  flags  that 
are  not  used  in  a  TCP/IP  network,  like  ECN  and  CWR,  set.  A  summary  of  the  packet  sent 
to  each  host  in  the  network  and  the  responses  received  from  them  is  presented  in  Table 
19. 
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Test  Case  1-Queso 

SYN  packet  without  options  to  an  open  port 


Packet  send 


IPV4 

HEADER  LENGTH 

TOS 

TOTAL  LENGTH 

FLAGS 

20 

0 

40 

0 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

TCP 

HEADER 

20 

FLAGS 

SYN 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server 
2003  Standard 
Edition 

Windows  XP  Pro  SP  2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

HEADER  LENGTH 

20 

20 

20 

20 

20 

20 

20 

20 

TOS 

0 

0 

0 

0 

0 

0 

0 

0 

IPV4 

TOTAL  LENGTH 

44 

44 

44 

44 

44 

44 

44 

44 

FLAGS 

0 

0 

DF 

DF 

DF 

DF 

DF 

DF 

TTL 

128 

128 

128 

64 

64 

64 

64 

64 

SEQUENCE 

ISN 

ISN 

ISN 

ISN 

ISN 

ISN 

ISN 

ISN 

ACKNOWLEDGE 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

HEADER 

24 

24 

24 

24 

24 

24 

24 

24 

TCP 

FLAGS 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

WINDOW  SIZE 

16384 

16384 

16616/65535 

5840 

5840 

5840 

65535 

65535 

OPTIONS 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

Table  13.  Test  ease  1  by  Queso,  SYN  packet  without  options  to  an  open  port 
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Test  Case  2-Queso 


SYN,  ACK  packet  without  options  to  an  open  port 


Packet  send 


IPV4 

HEADER  LENGTH 

TOS 

TOTAL  LENGTH 

FLAGS 

20 

0 

40 

0 

SEQUENCE 

SEQ 

TCP 

ACKNOWLEDGE 

0 

HEADER 

20 

FLAGS 

SYN,  ACK 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP  2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

HEADER  LENGTH 

20 

20 

20 

20 

20 

20 

20 

20 

TOS 

0 

0 

0 

0 

0 

0 

0 

0 

IPV4 

TOTAL  LENGTH 

40 

40 

40 

40 

40 

40 

40 

40 

FLAGS 

0 

0 

0 

DF 

DF 

DF 

DF 

0 

TTL 

128 

128 

128 

64 

64 

64 

64 

64 

SEQUENCE 

0 

0 

0 

0 

0 

0 

0 

0 

ACKNOWLEDGE 

0 

0 

0 

0 

0 

0 

0 

0 

TCP 

HEADER 

20 

20 

20 

20 

20 

20 

20 

20 

FLAGS 

RST 

RST 

RST 

RST 

RST 

RST 

RST 

RST 

WINDOW  SIZE 

0 

0 

0 

0 

0 

0 

0 

0 

Table  14.  Test  ease  2  by  Queso,  SYN,  ACK  paeket  without  options  to  an  open  port 
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Test  Case  3-Queso 


FIN  packet  without  options  to  an  open  port 


Packet  send 


IPV4 

HEADER  LENGTH 

TOS 

TOTAL  LENGTH 

FLAGS 

20 

0 

40 

0 

SEQUENCE 

SEQ 

TCP 

ACKNOWLEDGE 

0 

HEADER 

20 

FLAGS 

FIN 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP  2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

HEADER  LENGTH 

20 

20 

20 

TOS 

0 

0 

0 

IPV4 

TOTAL  LENGTH 

40 

40 

40 

NO  REPLY 

NO  REPLY 

NO  REPLY 

NO  REPLY 

NO  REPLY 

FLAGS 

0 

0 

0 

TTL 

128 

128 

128 

SEQUENCE 

0 

0 

0 

ACKNOWLEDGE 

SEQ+  + 

SEQ+  + 

SEQ+  + 

TCP 

HEADER 

20 

20 

20 

FLAGS 

RST,  ACK 

RST,  ACK 

RST,  ACK 

WINDOW  SIZE 

0 

0 

0 

Table  15.  Test  case  3  by  Queso,  FIN  packet  without  options  to  an  open  port. 
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Test  Case  4-Queso 


FIN,  ACK  packet  without  options  to  an  open  port 


Packet  send 


IPV4 

HEADER  LENGTH 

TOS 

TOTAL  LENGTH 

FLAGS 

20 

0 

40 

0 

SEQUENCE 

SEQ 

TCP 

ACKNOWLEDGE 

0 

HEADER 

20 

FLAGS 

FIN,  ACK 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP  2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

HEADER  LENGTH 

20 

20 

20 

20 

20 

20 

20 

20 

TOS 

0 

0 

0 

0 

0 

0 

0 

0 

IPV4 

TOTAL  LENGTH 

40 

40 

40 

40 

40 

40 

40 

40 

FLAGS 

0 

0 

0 

DF 

DF 

DF 

DF 

DF 

TTL 

128 

128 

128 

64 

64 

64 

64 

64 

SEQUENCE 

0 

0 

0 

0 

0 

0 

0 

0 

ACKNOWLEDGE 

0 

0 

0 

0 

0 

0 

0 

0 

TCP 

HEADER 

20 

20 

20 

20 

20 

20 

20 

20 

FLAGS 

RST 

RST 

RST 

RST 

RST 

RST 

RST 

RST 

WINDOW  SIZE 

0 

0 

0 

0 

0 

0 

0 

0 

Table  16.  Test  ease  4  by  Queso,  FIN,  ACK  paeket  without  options  to  an  open  port. 
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Test  Case  5-Queso 


SYN,  FIN  packet  without  options  to  an  open  port 


Packet  send 


IPV4 

HEADER  LENGTH 

TOS 

TOTAL  LENGTH 

FLAGS 

20 

0 

40 

0 

SEQUENCE 

SEQ 

TCP 

ACKNOWLEDGE 

0 

HEADER 

20 

FLAGS 

SYN,  FIN 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP  2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

HEADER  LENGTH 

20 

20 

20 

20 

20 

20 

20 

TOS 

0 

0 

0 

0 

0 

0 

0 

IPV4 

TOTAL  LENGTH 

44 

44 

44 

44 

44 

44 

44 

FLAGS 

0 

0 

DF 

DF 

DF 

DF 

DF 

NO  REPLY 

TTL 

128 

128 

128 

64 

64 

64 

64 

SEQUENCE 

ISN 

ISN 

ISN 

ISN 

ISN 

ISN 

ISN 

ACKNOWLEDGE 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

HEADER 

24 

24 

24 

24 

24 

24 

24 

TCP 

FLAGS 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

WINDOW  SIZE 

16384 

16384 

65535 

5840 

5840 

5840 

65535 

OPTIONS 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

Table  17.  Test  ease  5  by  Queso,  SYN,  FIN  paeket  without  options  to  an  open  port 
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Test  Case  6-Queso 


PSH  packet  without  options  to  an  open  port 


Packet  send 


IPV4 

HEADER  LENGTH 

TOS 

TOTAL  LENGTH 

FLAGS 

20 

0 

40 

0 

SEQUENCE 

SEQ 

TCP 

ACKNOWLEDGE 

0 

HEADER 

20 

FLAGS 

PSH 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP 

2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

HEADER  LENGTH 

20 

20 

20 

TOS 

0 

0 

0 

IPV4 

TOTAL  LENGTH 

40 

44 

44 

FLAGS 

0 

0 

0 

NO  REPLY 

NO  REPLY 

NO  REPLY 

NO  REPLY 

NO  REPLY 

TTL 

128 

128 

128 

SEQUENCE 

0 

0 

0 

ACKNOWLEDGE 

SEQ 

SEQ 

SEQ 

TCP 

HEADER 

20 

20 

20 

FLAGS 

RST,  ACK 

RST,  ACK 

RST,  ACK 

WINDOW  SIZE 

0 

0 

0 

Table  18.  Test  ease  6  by  Queso,  PSH  paeket  without  options  to  an  open  port 
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Test  Case  7-Queso 


SYN,  ECN,  CWR  packet  without  options  to  an  open  port 


Packet  send 


IPV4 

HEADER  LENGTH 

TOS 

TOTAL  LENGTH 

FLAGS 

20 

0 

40 

0 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

TCP 

HEADER 

20 

FLAGS 

SYN,  ECN,  CWR 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP  2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

HEADER  LENGTH 

20 

20 

20 

20 

20 

20 

20 

20 

TOS 

0 

0 

0 

0 

0 

0 

0 

0 

IPV4 

TOTAL  LENGTH 

44 

44 

44 

44 

44 

44 

44 

44 

FLAGS 

0 

0 

DF 

DF 

DF 

DF 

DF 

DF 

TTL 

128 

128 

128 

64 

64 

64 

64 

64 

SEQUENCE 

ISN 

ISN 

ISN 

ISN 

ISN 

ISN 

ISN 

ISN 

ACKNOWLEDGE 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

HEADER 

24 

24 

24 

24 

24 

24 

24 

24 

TCP 

FLAGS 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

WINDOW  SIZE 

16384 

16384 

65535 

5840 

5840 

5840 

65535 

65535 

OPTIONS 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

max  seg  size  :  1460 

Table  19.  Test  case  7  by  Queso,  SYN,  ECN,  CWR  packet  without  options  to  an  open  port 
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3,  Analysis 

From  the  results  presented  in  the  tables  above,  it  is  evident  that  not  all  OSes 
respond  with  the  same  values  in  their  headers.  Further,  there  are  eases  where  they  don’t 
even  exhibit  the  same  behavior.  The  key  differences  are  highlighted  below. 

a.  Don  V  Fragment  Bit  (DF) 

Not  all  OSes  set  the  don’t  fragment  bit  in  the  IPv4  header.  The  Windows 
servers  never  set  the  don’t  fragment  bit  in  their  response,  and  Windows  XP  sets  this  flag 
only  when  it  responds  with  a  SYN,  ACK  packet.  The  other  OSes  always  set  the  DF  bit 
except  in  the  case  of  the  ICMP  response. 

b.  TTL  Value 

The  Windows  OSes  always  set  this  value  to  128  and  the  other  OSes 
always  use  the  value  64.  The  TTL  value,  however,  cannot  be  used  explicitly  to 
characterize  the  OS.  This  is  because  the  TTL  is  set  from  the  sender  of  the  packet  to  some 
initial  value  and  decreases  by  one  every  time  the  packet  visits  an  intermediate  node. 
Thus,  this  value  can  only  be  used  implicitly  to  exclude  OSes.  For  example,  if  the  TTL 
value  in  a  received  packet  is  between  64  and  128,  that  host  could  not  be  an  OS  that  sets 
the  initial  TTL  value  to  64  or  possibly  less.  However  the  TTL  can  be  configured  to  an 
other  default  value  and  lead  to  inaccurate  conclusions.  Thus  it  can  not  be  considered  as  an 
accurate  factor  for  detecting  an  OS. 

c.  Window  Size 

The  window  size  is  actually  the  buffer  size  in  bytes  set  at  the  remote  host 
for  this  connection.  This  value  is  an  important  factor  for  OS  detection  because  many 
OSes  have  a  unique  value  among  the  other  OSes  that  by  itself  could  possibly  identify  the 
OS.  Also,  it  was  observed  that  the  Windows  and  the  Linux  machines  change  their 
window  size  value  depending  on  whether  the  packet  sent  to  that  host  included  options.  In 
contrast,  the  FreeBSD  machine  always  set  this  value  to  maximum  (65535  bytes).  So,  the 
Test  Cases  1  and  3  with  Nmap  included  options  in  the  TCP  headers  of  the  packets  sent  to 
the  target  host.  The  responses  received  from  the  Windows  servers  had  the  window  size 
value  set  to  16384,  Windows  XP  Pro  set  the  value  to  either  16430  or  65535,  the  Linux 
machines  set  that  value  to  5792,  and  the  FreeBSD  set  the  value  to  65535.  In  the  Test 
Cases  1,5,  and  7  with  Queso,  there  were  no  options  included  in  the  packet  sent  and  the 
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responses  received  from  the  Windows  servers  had  the  window  size  value  set  to  16384 
again,  Windows  XP  Pro  set  the  value  to  16616  or  65535,  the  Linux  machines  set  it  to 
5840,  and  the  FreeBSD  set  the  value  to  65535. 

d.  Options 

The  options  field  is  another  key  point  by  which  to  differentiate  OSes.  Not 
all  OSes  support  all  options.  For  those  options  supported,  they  do  not  list  the  supported 
options  in  the  same  order.  Furthermore,  it  was  observed  that,  while  some  OSes  may 
support  the  same  options  and  present  them  in  the  same  order,  they  may  support  different 
values  for  the  window  scale.  This  is  the  case  with  Fedora  Core  4  and  Red  Hat  Linux  9.0, 
where  Fedora  Core  4  sets  that  value  to  x4  and  Red  Hat  Linux  9.0  sets  the  value  to  xl. 

e.  Initial  Sequence  Number 

The  initial  sequence  number  is  the  value  chosen  by  the  OS  to  start 
counting  the  bytes  in  the  packets  it  sends  to  the  other  party  of  the  connection.  Although 
the  RFC  793  does  not  specify  any  fixed  pattern  for  choosing  the  ISN,  the  selection  must 
ensure  that  no  other  packet  belonging  to  the  same  connection  has  the  same  sequence 
number.  In  the  tests  presented  above,  the  value  of  the  sequence  number  is  presented  with 
SEQ,  referring  to  some  randomly  generated  value.  However,  Nmap  records  the  ISNs 
selected  from  the  remote  machine  and  attempts  to  find  a  pattern  in  the  selection  process 
that  the  OS  developer  may  have  used. 

f.  No  Reply 

There  are  some  cases  where  the  RFCs  do  not  specify  clearly  what  the 
appropriate  response  should  be  from  a  host  receiving  some  types  of  packets.  Thus,  the 
various  developers  of  the  TCP/IP  stacks  implement  different  behaviors  for  their  OSes. 
Examples  of  this  are  the  test  cases  of  the  NULE  packet,  PSH  packet,  and  the  PIN  packet 
as  presented  in  the  Tables  2,  11,  and  14  respectively.  In  those  cases,  only  the  Windows 
machines  sent  back  a  response. 

g.  ICMP  Port  Unreachable 

Pinally,  another  factor  that  helps  in  the  OS  detection  is  the  amount  of 
original  data  some  OSes  include  in  the  “ICMP  port  unreachable”  message  they  send 
back.  The  purpose  of  this  inclusion  is  for  the  other  host  to  be  able  to  identify  which 
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packet  initiated  the  ICMP  message.  However,  not  all  OSes  inelude  the  same  amount  of 
data,  as  is  apparent  in  the  ease  of  a  UDP  packet  sent  to  a  elosed  port  shown  in  Table  8. 


C.  APPLICABILITY  TO  IPV6  ENVIRONMENT 

The  previous  seetion  diseussed  OS  fingerprinting  as  it  may  be  eondueted  in  an 
IPv4  environment  using  two  different  tools  available  today,  Nmap  and  Queso.  These 
tools  use  the  same  eoneept  regarding  OS  detection.  Both  attempt  to  deteet  the  OS  by 
triggering  the  target  host  to  respond  to  speeially  eonstrueted  paekets  and  then  eomparing 
the  responses  to  a  database  eontaining  known  fingerprints.  If  a  match  is  found,  both  tools 
will  make  a  guess  about  the  OS  running  on  the  target  host.  However,  these  tools  use 
different  methods  for  triggering  the  protoeol  staek  of  the  target  host.  Eaeh  method  sends  a 
different  kind  of  paeket  in  order  to  trigger  a  specifie  response,  which  hopefully  will 
inelude  unique  values  for  some  fields  among  the  OSes.  That  means  that  the  deeision  as  to 
the  kind  of  the  paeket  to  be  sent  is  erueial  for  the  development  of  the  database  eontaining 
the  fingerprints  in  the  first  plaee. 

This  section  describes  an  attempt  to  apply  the  same  methods  used  by  Nmap  and 
Queso  in  an  IPv6  environment  and  examines  the  existenee  of  identifying  faetors  among 
the  OSes  of  the  network  of  Figure  2.  In  order  to  proeeed  to  the  aetual  tests  on  IPv6  it  is 
important  to  have  a  elear  knowledge  of  the  IPv6  header  format.  Also,  beeause  the 
objeetive  of  this  seetion  is  to  import  methods  from  the  IPv4  protoeol,  we  should  identify 
the  differenees  and  similarities  between  IPv4  and  IPv6  headers.  A  diseussion  of  these 
aspects  is  presented  in  the  following  two  paragraphs. 

1.  IPv6  vs  IPv4  Header  Format 

Any  paekets  sent  aeross  the  IPv6  network  must  eomply  with  the  IPv6  protoeol 
and,  therefore,  must  use  the  format  and  syntax  defined  by  the  RFC  2460.  Thus,  it  is 
evident  that  the  format  of  the  packets  as  they  were  eonstrueted  and  sent  by  the  tools  over 
the  IPv4  protoeol  eannot  be  sent  exaetly  the  same  way  over  the  IPv6  protoeol.  This  is 
beeause  IPv4  and  IPv6  protoeols  are  speeified  by  different  RFCs  and  use  different 
formats  for  their  headers. 
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The  format  of  the  IPv4  and  IPv6  headers  are  presented  in  the  Figures  II  and  12 
below.  The  most  important  differenees  between  these  two  header  formats  are  the 
following; 


0  12  3 

01234567890123456789012345678901 

.Version!  Type  of  Service!  Total  Length 

Identification  Flags  Fragment  Offset 

4-4-4-4-4--f-4-4-4-4--f-4-4-4-4-4-4-4-4-4-4-4--f-4-4-4-4-4-4-4-4-4-4 

Time  to  Live  Protocol  Header  Checksum 

Source  Address 
Destination  Address 

Options  Padding 

Figure  1 1 .  IPv4  header  format. 


Version  Traffic  Class  Flow  Label 

Payload  Length  Next  Header 

4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4 

4 

+  Source  Address 

4 

4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4 

4 

+  Destination  Address 

4 

4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4 

Figure  12.  IPv6  header  format. 


4-4-4-4-4-4-4-4-4 

4-4-4-4-4-4-4-4-4 

Hop  Limit 

4-4-4-4-4-4-4-4-4 

4 

4 

4 

4-4-4-4-4-4-4-4-4 

4 

4 

4 

4-4-4-4-4-4-4-4-4 
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a.  Header  Length 

The  header  length  in  the  IPv6  header  is  exaetly  40  bytes  long,  instead  of 
the  variable  length  in  the  IPv4  header.  This  is  the  reason  why  there  is  no  header  length 
field  in  the  IPv6  header. 

The  variable  length  in  the  IPv4  header  is  the  result  of  the  options  field  at 
the  end  of  the  header.  As  not  all  hosts  support  all  available  options,  and  because  not  all 
options  are  needed  for  every  packet  sent  across  the  network,  they  are  not  necessarily 
included  in  the  header,  so  the  IPv4  header  has  a  variable  length.  However,  in  the  IPv6 
header  this  field  has  been  removed,  so  that  the  header  has  a  constant  length. 

b.  Traffic  Class 

The  traffic  class  field  is  8  bits  long  and  is  similar  to  the  type  of  service 
(TOS)  field  of  the  of  the  IPv4  header.  The  traffic  class  field  in  the  IPv6  header  is 
available  for  use  by  originating  hosts  and/or  forwarding  routers  to  identify  and 
distinguish  between  different  classes  or  priorities  of  IPv6  packets. 

c.  Flow  Label 

The  flow  label  field  is  20  bits  long  and,  as  it  is  described  in  RFC  2460,  is 
still  experimental.  There  is  no  equivalent  field  in  the  IPv4  header.  Its  purpose  is  for  a 
source  to  label  sequences  of  packets  for  which  it  requests  special  handling  by  the  IPv6 
routers,  such  as  non-default  quality  of  service  or  "real-time"  service. 

d.  Payload  Length 

This  field  is  16  bits  long  and  it  is  similar  to  the  total  length  field  of  the 
IPv4  header.  The  difference  is  that  the  payload  length  gives  the  number  of  the  bytes 
following  the  IPv6  header.  That  means  that  any  extension  headers  are  included  in  the 
Payload  Length. 

e.  Next  Header 

This  field  is  8  bits  long  and  it  is  equivalent  to  the  protocol  field  in  IPv4 
header.  This  field  identifies  the  protocol  to  which  the  data  of  the  datagram  will  be 
delivered  and  it  uses  the  same  values  as  IPv4,  as  described  in  RFC  1700. 
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f.  Hop  Limit 

The  hop  limit  field  is  8  bits  long  and  is  similar  with  the  time  to  live  (TTL) 
field  in  the  IPv4  header.  The  value  of  the  hop  limit  is  initialized  by  the  originator  of  the 
paeket  and  it  is  deeremented  by  one  by  eaeh  node  that  forwards  the  packet. 

g.  Source  and  Destination  Address 

These  two  values  are  128bits  long  each  and  are  analogous  to  the  source 
and  destination  address  fields  in  the  IPv4  header. 

h.  Fragmentation 

The  IPv6  protocol  does  not  support  fragmentation  and  reassembly  at  the 
intermediate  nodes.  Those  operations  are  only  performed  at  the  source  and  destination 
hosts.  That  is  why  there  are  no  Identification,  Flags,  and  Fragment  Offset  fields  included 
in  the  IPv6  header.  However,  if  a  packet  is  received  that  is  too  large  to  be  forwarded  to 
the  outgoing  link,  the  router  will  drop  that  packet  and  send  to  the  packet  originator  an 
ICMP  error  message  “Packet  Too  Big”. 

L  Header  Checksum 

The  header  checksum  field  that  was  included  in  the  IPv4  header  has  been 
removed  from  the  IPv6  header.  This  is  because  the  TCP  and  UDP  protocols  at  the 
transport  layer  and  the  data  links  protocols,  like  Ethernet,  also  include  a  checksum  in 
their  headers.  It  seems  that  this  field  was  redundant  and  so  it  was  removed. 

j.  Options 

The  options  field  that  was  available  in  the  IPv4  header  has  been  removed 
from  IPv6.  However,  it  has  not  been  removed  from  the  protocol  stack  completely.  That 
is,  it  has  changed  so  that  the  available  options  become  a  separate  header  and  are  pointed 
to  by  the  Next  Header  field  in  the  IPv6  header.  So,  if  there  is  a  need  for  a  specific  kind  of 
option  or  options  to  be  included  in  the  packet  sent,  a  separate  header  for  each  of  them  will 
be  added  between  the  IPv6  and  the  transport  layer  header. 

2.  Equivalence  Of  IPv6  To  IPv4  Header  Fields 

The  methods  described  earlier  in  this  chapter  for  OS  detection  over  IPv4  send 
complete  frames  by  generating  headers  of  the  other  layers  of  the  protocol  stack.  That  is, 
they  should  include  a  transport  layer  header,  a  network  layer  header,  and  a  data  link  layer 
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header.  The  transport  and  data  link  layer  headers  are  not  affeeted  by  the  ehange  at  the 
network  layer  due  to  IPv6  protocol  entry.  This  is  a  characteristic  of  the  layered 
architecture  of  the  protocol  stack.  It  is  possible  to  use  the  same  format  for  these  two 
layers  over  both  IPv4  and  IPv6  protocols.  Thus,  there  is  no  doubt  about  the  applicability 
of  the  methods  that  use  values  of  the  Transport  layer  headers  for  identifying  the  different 
OSes.  One  point  of  which  we  should  be  aware  is  that  the  maximum  segment  size  that  is 
used  in  the  options  of  TCP  header  is  1460  bytes  for  IPv4  packets  but  in  the  case  of  IPv6 
this  value  should  be  1440  bytes.  That  is  because  the  IPv6  header  is  20  bytes  longer  than 
the  smallest  IPv4  header.  It  should  not  be  expected  that  the  OSes  will  use  the  same  values 
in  both  cases.  For  example,  it  may  be  possible  to  identify  the  OS  based  on  the  window 
size  value  used  in  the  TCP  header,  but  this  doesn’t  necessarily  means  that  this  value  will 
be  the  same  over  the  IPv4  and  IPv6  protocol. 

It  should  be  observed  that  although  the  transport  and  IP  layers  are  separate,  the 
vendors  of  the  OSes  develop  their  protocol  stack  with  these  two  layers  very  tightly 
coupled.  Also,  the  OS  should  be  able  to  implement  both  IPv4  and  IPv6,  thus  they  develop 
their  dual  protocol  stack  in  a  way  that  could  be  depicted  graphically  in  Figure  13. 


Application  Layer 


TCP/IPv4 


TCP/IPv6 


Link  Layer 


Physical  Layer 


Figure  13.  Dual  protocol  stack. 


Although  the  transport  and  data  link  headers  can  be  used  exactly  the  same  when 
probing  the  IPv6  protocol,  that  is  not  the  case  for  IP  header  itself.  Here  some 
modifications  should  be  applied  in  order  to  send  packets  over  IPv6.  It  was  noted  earlier 
that  not  all  fields  of  IPv4  have  an  equivalent  in  IPv6.  Also,  some  fields  have  been 
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removed  and  some  others  have  been  added  in  the  IPv6  header.  The  appropriate 
modifications  to  the  packets  sent  over  IPv4  are  the  following: 

•  Version:  It  must  change  from  4  to  6. 

•  Header  length:  There  is  no  equivalent  in  IPv6  and  it  can  be  ignored 

•  Type  of  service:  It  is  equivalent  with  the  traffic  class  in  IPv6.  No  default 
values  should  be  tested. 

•  Total  length:  There  is  no  equivalent  in  IPv6  and  it  should  be  ignored. 

•  Identification/fiags/fragment  offset:  These  values  do  not  have  an 
equivalent  in  the  IPv6  and  should  be  ignored.  However,  the  DF  flag  was  a 
key  factor  for  identifying  among  OSes.  So,  this  identifying  factor  will  not 
be  available  in  IPv6. 

•  Time  to  live:  It  is  equivalent  to  hop  limit  in  the  IPv6,  so  it  can  have  the 
same  or  different  values. 

•  Protocol:  This  is  equivalent  to  the  next  header  in  the  IPv6.  Both  protocols 
use  the  values  described  in  RFC  1700. 

•  Internet  checksum:  There  is  no  equivalent  field  in  the  IPv6  header  and  it 
can  be  ignored. 

•  Source/destination  address:  This  is  analogous  to  the  source  and  destination 
address  in  the  IPv6.  However,  in  the  IPv6  header  these  addresses  are  128 
bits  long.  They  are  still  used  for  identifying  the  source  and  destination. 

•  Options:  There  is  no  equivalent  field  in  the  IPv6  header.  Instead,  a 
separate  header  is  added  between  the  IPv6  and  transport  layer  headers  for 
any  desired  option,  which  is  identified  through  the  next  header  field  in  the 
IPv6  header. 
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D,  APPLICABILITY  OF  KNOWN  METHODS  OVER  IPV6  PROTOCOL 

Eight  methods  used  from  Nmap  and  seven  more  from  Queso  were  explored 
earlier  in  this  ehapter.  We  turn  now  to  the  applieability  of  those  methods  for 
distinguishing  the  OS  when  employing  the  IPv6  protoeol. 

1.  Applicability  of  the  Methods  Used  by  Nmap 

a.  Test  case  1,  SYN,  ECN packet  with  options  to  an  open  port 

This  method  sends  a  paeket  with  the  SYN  and  ECN  bits  set  and  some 
options  ineluded  in  the  TCP  header.  This  paeket  is  a  request  for  setting  up  a  eonneetion 
with  the  remote  host  on  the  port  number  speeified  in  the  port  number  field  of  the  paeket 
sent.  The  eommon  behavior  of  the  host  whieh  has  the  port  listening  for  ineoming 
eonneetions  is  to  aeknowledge  the  request  and  respond  with  a  SYN,  ACK  paeket.  A 
summary  of  the  paeket  sent  to  eaeh  host  in  the  network  and  the  responses  reeeived  from 
them  is  presented  in  Table  20. 

b.  Test  case  2,  NULL  packet  with  options  to  an  open  port 

This  method  sends  a  paeket  with  no  flags  set  and  some  options  ineluded  in 
the  TCP  header.  A  summary  of  the  paeket  sent  to  eaeh  host  in  the  network  and  the 
responses  reeeived  from  them  is  presented  in  Table  21. 

c.  Test  case  3,  FLN,  SYN,  PSH,  URG  packet  with  options  to  an 
open  port 

This  method  sends  a  paeket  with  the  PIN,  SYN,  PSH,  URG  bits  set  and 
some  options  ineluded  in  the  TCP  header.  A  summary  of  the  paeket  sent  to  eaeh  host  in 
the  network  and  the  responses  reeeived  from  eaeh  them  is  presented  in  Table  22. 

d.  Test  case  4,  ACK  packet  with  options  to  an  open  port 

This  method  sends  a  paeket  with  the  ACK  flag  set  and  some  options 
ineluded  in  the  TCP  header.  This  paeket  originally  aeknowledges  a  paeket  sent  from  the 
remote  host.  Beeause  no  paeket  was  sent  from  that  host,  the  eommon  response  is  for  the 
target  host  to  send  baek  a  paeket  with  the  RST  flag  set.  A  summary  of  the  paeket  sent  to 
eaeh  host  in  the  network  and  the  responses  reeeived  from  them  is  presented  in  Table  23. 

e.  Test  case  5,  SYN  packet  with  options  to  a  closed  port 

This  method  sends  a  paeket  with  the  SYN  flag  set  and  some  options 
ineluded  in  the  TCP  header  to  a  elosed  port.  This  is  a  request  to  establish  a  eonneetion 
with  the  remote  host  on  the  speeified  port  number.  Beeause  the  port  is  elosed,  the  remote 
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host  must  reject  the  request  and  send  back  a  packet  with  the  RST  and  ACK  flags  set.  A 
summary  of  the  packet  sent  to  each  host  in  the  network  and  the  responses  received  from 
them  is  presented  in  Table  24. 

f.  Test  case  6,  ACK  packet  with  options  to  a  closed  port 

This  method  sends  a  packet  with  the  ACK  flag  set  and  some  options 
included  in  the  TCP  header  to  a  closed  port.  The  ACK  flag  indicates  that  the  sender 
acknowledges  some  data  sent  from  the  remote  host.  In  this  case,  however,  the  remote 
host  has  neither  sent  any  data  nor  is  it  listening  to  the  indicated  port  for  incoming  packets. 
Thus,  the  remote  host  sends  back  a  packet  with  the  RST  flag  set.  A  summary  of  the 
packet  sent  to  each  host  in  the  network  and  the  responses  received  from  them  is  presented 
in  Table  25. 

g.  Test  case  7,  ACK  packet  with  options  to  a  closed  port 

This  method  sends  a  packet  with  the  FIN,  PSH,  and  URG  flags  set  and 
some  options  included  in  the  TCP  header  to  a  closed  port.  The  FIN  flag  in  the  header 
indicates  that  the  sender  is  attempting  to  close  a  connection,  but  because  there  is  no  active 
connection,  the  remote  host  sends  back  a  packet  with  the  RST/ACK  flags  set.  A  summary 
of  the  packet  sent  to  each  host  in  the  network  and  the  responses  received  from  them  is 
presented  in  Table  26. 

h.  Test  case  8,  UDP  packet  with  data  to  a  closed  port 

This  method  sends  a  UDP  packet  to  a  closed  port.  The  expected  response 
is  for  the  remote  host  to  send  back  an  ICMP  error  message,  “port  unreachable”  (type  1, 
code  4).  A  summary  of  the  packet  sent  to  each  host  in  the  network  and  the  responses 
received  from  them  is  presented  in  Table  27. 
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Test  Case  1-Modified  from  Nmap 


SYN,  ECN  packet  with  options  to  a  open  port 


Packet  send 


TRAFFIC  CLASS 

X 

FLOW  LABEL 

Y 

IPV6 

PAYLOAD 

40 

HOP  LIMIT 

64 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

HEADER 

40 

TCP 

FLAGS 

SYN,  ECN 

OPTIONS 

max  seg  size  :  1440 
SACK  permitted 

Time  stamp  :  X,  0 

NOP 

Win  Scale  :  10 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

TRAFFIC  CLASS 

0 

0 

0 

0 

0 

0 

00/03/08/0D/0E 

0 

FLOW  LABEL 

0 

0 

0 

0 

0 

0 

RANDOM# 

RANDOM# 

IPV6 

PAYLOAD 

24 

24 

24 

40 

40 

40 

44 

40 

HOP  LIMIT 

128 

128 

128 

64 

64 

64 

64 

64 

SEQUENCE 

ACKNOWLEDGE 

ISN 

SEQ+  + 

ISN 

SEQ+  + 

ISN 

SEQ+  + 

ISN 

SEQ+  + 

ISN 

SEQ+  + 

ISN 

SEQ+  + 

ISN 

SEQ+  + 

ISN 

SEQ+  + 

HEADER 

24 

24 

24 

40 

40 

40 

44 

40 

FLAGS 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

TCP 

WINDOW  SIZE 

17280 

17280 

17280 

5712 

5712 

5712 

65535 

65535 

OPTIONS 

Max  seg  size  :  1440 

Max  seg  size  :  1440 

Max  seg  size  :  1440 

Max  seg  size  :  1440 
SACK  permitted 

Time  Stamp  :  X, 

NOP 

Win  Scale  :  2(X4) 

Max  seg  size  :  1440 
SACK  permitted 

Time  Stamp  :  X,  Y 

NOP 

Win  Scale  :  2(X4) 

Max  seg  size  :  1440 
SACK  permitted 

Time  Stamp  :  X,  Y 

NOP 

Win  Scale  :  0(X1) 

Max  seg  size  :  1440 
NOP 

Win  Scale  :  1(X2) 

NOP 

NOP 

Time  Stamp  :  X,  Y 

EOL 

Max  seg  size  :  1440 
NOP 

Win  Scale  :  0(X1) 

NOP 

NOP 

Time  Stamp  :  X,  Y 

Table  20.  Test  ease  1  modified  from  Nmap,  SYN,  ECN  packet  with  options  to  an  open  port. 
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Test  Case  2-  Modified  from  Nmap 

NULL  packet  with  options  to  an  open  port 


Packet  send 


TRAFFIC  CLASS 

X 

FLOW  LABEL 

Y 

IPV6 

PAYLOAD 

40 

HOP  LIMIT 

64 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

HEADER 

40 

TCP 

FLAGS 

— 

OPTIONS 

max  seg  size  :  1440 

SACK  permitted 

Time  stamp  :  X,  0 

NOP 

Win  Scale  :  10 

Windows  Server  2003 

Windows  Server  2003 

Windows  XP  Pro  SP2 

Red  Hat  Enterprise 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

Packet  received 

Enterprise  Edition  SPl 

Standard  Edition 

Linux  4  WS 

TRAFFIC  CLASS 

0 

0 

0 

FLOW  LABEL 

0 

0 

0 

NO  REPLY 

NO  REPLY 

NO  REPLY 

NO  REPLY 

NO  REPLY 

IPV6 

PAYLOAD 

20 

20 

20 

HOP  LIMIT 

128 

128 

128 

SEQUENCE 

0 

0 

0 

ACKNOWLEDGE 

SEQ 

SEQ 

SEQ 

HEADER  LENGTH 

20 

20 

20 

TCP 

FLAGS 

RST,  ACK 

RST,  ACK 

RST,  ACK 

WINDOW  SIZE 

0 

0 

0 

OPTIONS 

-- 

-- 

-- 

Table  21 .  Test  case  2  modified  from  Nmap,  NULL  packet  with  options  to  an  open  port. 
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Test  Case  3-  Modified  from  Nmap 

SYN,  FIN,  PSH,  URG  packet  with  options  to  an  open  port 


Packet  send 


TRAFFIC  CLASS 

X 

FLOW  LABEL 

Y 

IPV6 

PAYLOAD 

40 

HOP  LIMIT 

64 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

FLAGS 

SYN,  FIN,  PSH,  URG 

TCP 

HEADER 

40 

OPTIONS 

max  seg  size  :  1440 
SACK  permitted 

Time  stamp  :  X,  0 

NOP 

Win  Scale  :  10 

Packet  received 

Windows  Server  2003 
EnterpriseEnterprise 
Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

TRAFFIC  CLASS 

0 

0 

0 

0 

0 

0 

0 

FLOW  LABEL 

0 

0 

0 

0 

0 

0 

RANDOM 

IPV6 

NO  REPLY 

PAYLOAD 

24 

24 

24 

40 

40 

40 

44 

HOP  LIMIT 

128 

128 

128 

64 

64 

64 

64 

SEQUENCE 

ISN 

ISN 

ISN 

ISN 

ISN 

ISN 

ISN 

ACKNOWLEDGE 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

HEADER  LENGTH 

24 

24 

24 

40 

40 

40 

44 

FLAGS 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

WINDOW  SIZE 

17280 

17280 

17280 

5712 

5712 

5712 

65535 

TCP 

OPTIONS 

Max  seg  size  :  1440 

Max  seg  size  :  1440 

Max  seg  size  :  1440 

Max  seg  size  :  1440 

Max  seg  size  :  1440 

Max  seg  size  :  1440 

Max  seg  size  :  1440 

SACK  permitted 

Time  Stamp  :  X,  Y 

NOP 

Win  Scale  :  2(X4) 

SACK  permitted 

Time  Stamp  :  X,  Y 

NOP 

Win  Scale  :  2(X4) 

SACK  permitted 

Time  Stamp  :  X,  Y 

NOP 

Win  Scale  :  0(X1) 

NOP 

Win  Scale  :  1(X2) 

NOP 

NOP 

Time  Stamp  :  X,  Y 

SACK  permitted 

EOL 

Table  22.  Test  case  3  modified  from  Nmap,  FIN,  SYN,  PSH,  URG  packet  with  options  to  an  open  port 
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Test  Case  4-  Modified  from  Nmap 

ACK  packet  with  options  to  an  open  port 


Packet  send 


TRAFFIC  CLASS 

X 

FLOW  LABEL 

Y 

IPV6 

PAYLOAD 

40 

HOP  LIMIT 

64 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

HEADER 

40 

TCP 

OPTIONS 

max  seg  size  :  1440 
SACK  permitted 

Time  stamp  :  X,  0 

NOP 

Win  Scale  :  10 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

TRAFFIC  CLASS 

0 

0 

0 

0 

0 

0 

0 

X 

FLOW  LABEL 

0 

0 

0 

0 

0 

0 

0 

Y 

IPV6 

PAYLOAD 

20 

20 

20 

20 

20 

20 

20 

20 

HOP  LIMIT 

128 

128 

128 

64 

64 

64 

64 

64 

SEQUENCE 

0 

0 

0 

0 

0 

0 

0 

0 

ACKNOWLEDGE 

0 

0 

0 

0 

0 

0 

0 

0 

HEADER  LENGTH 

20 

20 

20 

20 

20 

20 

20 

20 

TCP 

FLAGS 

RST 

RST 

RST 

RST 

RST 

RST 

RST 

RST 

WINDOW  SIZE 

0 

0 

0 

0 

0 

0 

0 

0 

OPTIONS 

— 

— 

— 

— 

— 

— 

— 

— 

Table  23.  Test  case  4  modified  from  Nmap,  ACK  packet  with  options  to  an  open  port 
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Test  Case  5-  Modified  from  Nmap 

SYN  packet  with  options  to  a  closed  port 


Packet  send 


TRAFFIC  CLASS 

X 

FLOW  LABEL 

Y 

IPV6 

PAYLOAD 

40 

HOP  LIMIT 

64 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

FLAGS 

SYN 

TCP 

HEADER 

40 

OPTIONS 

max  seg  size  :  1440 
SACK  permitted 

Time  stamp  :  X,  0 

NOP 

Win  Scale  :  2(x4) 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

TRAFFIC  CLASS 

0 

0 

0 

0 

0 

0 

0 

X 

FLOW  LABEL 

0 

0 

0 

0 

0 

0 

0 

Y 

IPV6 

PAYLOAD 

20 

20 

20 

20 

20 

20 

20 

20 

HOP  LIMIT 

128 

128 

128 

64 

64 

64 

64 

64 

SEQUENCE 

0 

0 

0 

0 

0 

0 

0 

0 

ACKNOWLEDGE 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

HEADER 

20 

20 

20 

20 

20 

20 

20 

20 

TCP 

FLAGS 

RST,  ACK 

RST,  ACK 

RST,  ACK 

RST,  ACK 

RST,  ACK 

RST,  ACK 

RST,  ACK 

RST,  ACK 

WINDOW  SIZE 

0 

0 

0 

0 

0 

0 

0 

0 

OPTIONS 

-- 

-- 

-- 

-- 

-- 

-- 

-- 

-- 

Table  24. 


Test  case  5  modified  from  Nmap,  SYN  packet  with  options  to  a  closed  port. 
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Test  Case  6-  Modified  from  Nmap 

ACK  packet  with  options  to  a  closed  port 


Packet  send 


TRAFFIC  CLASS 

X 

FLOW  LABEL 

Y 

IPV6 

PAYLOAD 

40 

HOP  LIMIT 

64 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

HEADER  LENGTH 

40 

TCP 

FLAGS 

ACK 

OPTIONS 

max  seg  size  :  1440 
SACK  permitted 

Time  stamp  :  X,  0 

NOP 

Win  Scale  :  10 

Packet  received 

Windows  Server 

Windows  Server 

Windows  XP  Pro  SP2 

Red  Hat  Enterprise 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

2003  Enterprise 

Edition  SPl 

2003  Standard 

Edition 

Linux  4  WS 

TRAFFIC  CLASS 

0 

0 

0 

0 

0 

0 

0 

X 

FLOW  LABEL 

0 

0 

0 

0 

0 

0 

0 

Y 

IPV6 

PAYLOAD 

20 

20 

20 

20 

20 

20 

20 

20 

HOP  LIMIT 

128 

128 

128 

64 

64 

64 

64 

64 

SEQUENCE 

0 

0 

0 

0 

0 

0 

0 

0 

ACKNOWLEDGE 

0 

0 

0 

0 

0 

0 

0 

0 

HEADER 

20 

20 

20 

20 

20 

20 

20 

20 

TCP 

FLAGS 

RST 

RST 

RST 

RST 

RST 

RST 

RST 

RST 

WINDOW  SIZE 

0 

0 

0 

0 

0 

0 

0 

0 

OPTIONS 

-- 

-- 

-- 

-- 

-- 

-- 

-- 

-- 

Table  25.  Test  case  6  modified  from  Nmap,  ACK  packet  with  options  to  a  closed  port. 
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Test  Case  7-  Modified  from  Nmap 

FIN,  PSH,  URG  packet  with  options  to  a  closed  port 


Packet  send 


TRAFFIC  CLASS 

X 

FLOW  LABEL 

Y 

IPV6 

PAYLOAD 

40 

HOP  LIMIT 

64 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

HEADER  LENGTH 

40 

TCP 

FLAGS 

FIN,  PSH,  URG 

OPTIONS 

max  seg  size  :  1440 
SACK  permitted 

Time  stamp  :  X,  0 

NOP 

Win  Scale  :  10 

Packet  received 

Windows  Server  2003 
Enterprise  Edition 

SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro 
SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

TRAFFIC  CLASS 

0 

0 

0 

0 

0 

0 

0 

X 

FLOW  LABEL 

0 

0 

0 

0 

0 

0 

0 

Y 

IPV6 

PAYLOAD 

20 

20 

20 

20 

20 

20 

20 

20 

HOP  LIMIT 

128 

128 

128 

64 

64 

64 

64 

64 

SEQUENCE 

0 

0 

0 

0 

0 

0 

0 

0 

ACKNOWLEDGE 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ 

SEQ 

TCP 

HEADER  LENGTH 

FLAGS 

WINDOW  SIZE 

OPTIONS 

20 

RST,  ACK 

0 

20 

RST,  ACK 

0 

20 

RST,  ACK 

0 

20 

RST,  ACK 

0 

20 

RST,  ACK 

0 

20 

RST,  ACK 

0 

20 

RST,  ACK 

0 

20 

RST,  ACK 

0 

Table  26.  Test  ease  7  modified  from  Nmap,  F 

N,  PSH,  URG  paeket  with  options  to  a  elosec 

port. 
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Test  Case  8-  Modified  from  Nmap 

UDP  packet  to  a  closed  port 

Packet  send 


TRAFFIC  CLASS 

X 

IPV6 

FLOW  LABEL 

Y 

PAYLOAD 

1208 

HOP  LIMIT 

64 

UDP 

DATA 

1200  Bytes 

Packet  received 

Windows  Server  2003 
Enterprise  Edition 

SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro 
SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

TRAFFIC  CLASS 

0 

0 

0 

0 

0 

0 

0 

0 

FLOW  LABEL 

0 

0 

0 

0 

0 

0 

0 

0 

IPV6 

PAYLOAD 

1240 

1240 

1240 

1240 

1240 

1240 

1240 

1240 

HOP  LIMIT 

128 

128 

128 

64 

64 

64 

64 

64 

TYPE 

1 

1 

1 

1 

1 

1 

1 

1 

ICMP 

CODE 

4 

4 

4 

4 

4 

4 

4 

4 

DATA 

1184  Bytes 

1184  Bytes 

1184  Bytes 

1184  Bytes 

1184  Bytes 

1184  Bytes 

1184  Bytes 

1184  Bytes 

Table  27.  Test  ease  8  modified  from  Nmap,  UDP  paeket  with  data  to  a  elosed  port. 
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2,  Applicability  of  the  Methods  Used  by  Queso 

a.  Test  case  1,  SYN packet  without  options  to  an  open  port 

In  this  method,  a  common  request  for  setting  up  a  connection! i  with  the 
target  host,  on  a  specified  port  number,  is  sent  to  the  target  host.  The  expected  action  for 
a  machine  which  listens  for  incoming  requests  is  to  accept  the  request  and  respond  with  a 
SYN,  ACK  packet.  A  summary  of  the  packet  sent  to  each  host  in  the  network  and  the 
responses  received  from  them  is  presented  in  Table  28. 

b.  Test  case  2,  SYN,  ACK  packet  without  options  to  an  open  port 

In  this  method,  a  packet  is  sent  that  actually  accepts  an  incoming  request 
to  set  up  a  connection.  Because  no  request  has  been  sent  from  the  target  host,  that  host 
will  send  back  a  RST  packet.  A  summary  of  the  packet  sent  to  each  host  in  the  network 
and  the  responses  received  from  them  is  presented  in  Table  29. 

c.  Test  case  3,  FIN  packet  without  options  to  an  open  port 

In  this  method,  a  packet  is  sent  with  the  FIN  flag  set.  In  this  case,  the  way 
the  remote  machines  respond  may  vary.  A  summary  of  the  packet  sent  to  each  host  in  the 
network  and  the  responses  received  from  them  is  presented  in  Table  30. 

d.  Test  case  4,  FIN,  ACK  packet  without  options  to  an  open  port 

In  this  method,  a  packet  is  sent  with  the  FIN  and  ACK  flags  set.  A 
summary  of  the  packet  sent  to  each  host  in  the  network  and  the  responses  received  from 
them  is  presented  in  Table  3 1 . 

e.  Test  case  5,  SYN,  FIN  packet  without  options  to  an  open  port 

In  this  method,  a  packet  is  sent  with  the  SYN  and  FIN  flags  set.  A 
summary  of  the  packet  sent  to  each  host  in  the  network  and  the  responses  received  from 
them  is  presented  in  Table  32. 

f.  Test  case  6,  PSH packet  without  options  to  an  open  port 

In  this  method,  a  packet  is  sent  with  the  PSH  flag  set.  A  summary  of  the 
packet  sent  to  each  host  in  the  network  and  the  responses  received  from  them  is  presented 
in  Table  33. 


! !  This  is  the  first  part  of  the  3 -way  handshake  between  client  and  server. 
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g.  Test  case  7,  SYN,  ECN,  CWR  packet  without  options  to  an  open 
port 

In  this  method,  a  packet  is  sent  with  the  SYN  flag  and  two  additional  flags 
that  are  not  used  in  a  TCP/IP  network,  such  as  ECN  and  CWR,  set.  A  summary  of  the 
packet  sent  to  each  host  in  the  network  and  the  responses  received  from  them  is  presented 
in  Table  34. 
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Test  Case  1-  Modified  from  Queso 

SYN  packet  without  options  to  an  open  port 


Packet  send 


IPV6 

TRAFFIC  CLASS 

FLOW  LABEL 

PAYLOAD 

HOP  LIMIT 

X 

Y 

20 

255 

TCP 

SEQUENCE 

ACKNOWLEDGE 

HEADER 

FLAGS 

SEQ 

0 

20 

SYN 

Packet  received 

Windows  Server  2003 
Enterprise  Edition 

SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro 
SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

TRAFFIC  CLASS 

0 

0 

0 

0 

0 

0 

0 

0 

FLOW  LABEL 

0 

0 

0 

0 

0 

0 

RANDOM 

RANDOM 

IPV6 

PAYLOAD 

24 

24 

24 

24 

24 

24 

24 

24 

HOP  LIMIT 

128 

128 

128 

64 

64 

64 

64 

64 

TCP 

SEQUENCE 

ACKNOWLEDGE 

HEADER 

FLAGS 

ISN 

SEQ+  + 

24 

SYN,  ACK 

ISN 

SEQ+  + 

24 

SYN,  ACK 

ISN 

SEQ+  + 

24 

SYN,  ACK 

ISN 

SEQ+  + 

24 

SYN,  ACK 

ISN 

SEQ+  + 

24 

SYN,  ACK 

ISN 

SEQ+  + 

24 

SYN,  ACK 

ISN 

SEQ+  + 

24 

SYN,  ACK 

ISN 

SEQ+  + 

24 

SYN,  ACK 

WINDOW  SIZE 

17080 

17080 

17080 

5760 

5760 

5760 

65535 

65535 

OPTIONS 

max  seg  size:  1440 

max  seg  size:  1440 

max  seg  size:  1440 

max  seg  size:  1440 

max  seg  size:  1440 

max  seg  size:  1440 

max  seg  size:  1440 

max  seg  size:  1440 

Table  28.  Test  case  1  modified  from  Queso,  SYN  packet  without  options  to  an  open  port 
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Test  Case  2-  Modified  from  Queso 

SYN,  ACK  packet  without  options  to  an  open  port 


Packet  send 


IPV6 

TRAFFIC  CLASS 

FLOW  LABEL 

PAYLOAD 

HOP  LIMIT 

X 

Y 

20 

255 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

TCP 

HEADER 

20 

FLAGS 

SYN,  ACK 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro 
SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

TRAFFIC  CLASS 

0 

0 

0 

0 

0 

0 

0 

X 

FLOW  LABEL 

0 

0 

0 

0 

0 

0 

0 

Y 

IPV6 

PAYLOAD 

20 

20 

20 

20 

20 

20 

20 

20 

HOP  LIMIT 

128 

128 

128 

64 

64 

64 

64 

64 

SEQUENCE 

0 

0 

0 

0 

0 

0 

0 

0 

ACKNOWLEDGE 

0 

0 

0 

0 

0 

0 

0 

0 

HEADER 

20 

20 

20 

20 

20 

20 

20 

20 

TCP 

FLAGS 

RST 

RST 

RST 

RST 

RST 

RST 

RST 

RST 

WINDOW  SIZE 

0 

0 

0 

0 

0 

0 

0 

0 

OPTIONS 

-- 

-- 

-- 

-- 

-- 

-- 

-- 

-- 

Table  29.  Test  ease  2  modified  from  Queso,  SYN,  ACK  paeket  without  options  to  an  open  port. 
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Test  Case  3-  Modified  from  Queso 

FIN  packet  without  options  to  an  open  port 


Packet  send 


IPV6 

TRAFFIC  CLASS 

FLOW  LABEL 

PAYLOAD 

HOP  LIMIT 

X 

Y 

20 

255 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

TCP 

HEADER 

20 

FLAGS 

FIN 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro 
SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

TRAFFIC  CLASS 

0 

0 

0 

FLOW  LABEL 

0 

0 

0 

TDX  1C. 

NO  REPLY 

NO  REPLY 

NO  REPLY 

NO  REPLY 

NO  REPLY 

IrV  D 

PAYLOAD 

20 

20 

20 

HOP  LIMIT 

128 

128 

128 

SEQUENCE 

0 

0 

0 

ACKNOWLEDGE 

SEQ+  + 

SEQ+  + 

SEQ+  + 

HEADER 

20 

20 

20 

TCP 

FLAGS 

RST,  ACK 

RST,  ACK 

RST,  ACK 

WINDOW  SIZE 

0 

0 

0 

OPTIONS 

-- 

-- 

-- 

Table  30.  Test  case  3  modified  from  Queso,  FIN  packet  without  options  to  an  open  port 
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Test  Case  4-  Modified  from  Queso 

FIN,  ACK  packet  without  options  to  an  open  port 


Packet  send 


IPV6 

TRAFFIC  CLASS 

FLOW  LABEL 

PAYLOAD 

HOP  LIMIT 

X 

Y 

20 

255 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

TCP 

HEADER 

20 

FLAGS 

FIN,  ACK 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro 
SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

TRAFFIC  CLASS 

0 

0 

0 

0 

0 

0 

0 

X 

FLOW  LABEL 

0 

0 

0 

0 

0 

0 

0 

Y 

IPV6 

PAYLOAD 

20 

20 

20 

20 

20 

20 

20 

20 

HOP  LIMIT 

128 

128 

128 

64 

64 

64 

64 

64 

SEQUENCE 

0 

0 

0 

0 

0 

0 

0 

0 

ACKNOWLEDGE 

0 

0 

0 

0 

0 

0 

0 

0 

HEADER 

20 

20 

20 

20 

20 

20 

20 

20 

TCP 

FLAGS 

RST 

RST 

RST 

RST 

RST 

RST 

RST 

RST 

WINDOW  SIZE 

0 

0 

0 

0 

0 

0 

0 

0 

OPTIONS 

— 

— 

— 

— 

— 

— 

— 

— 

Table  31.  Test  case  4  modified  from  Queso,  FIN,  ACK  packet  without  options  to  an  open  port 
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Test  Case  5-  Modified  from  Queso 

SYN,  FIN  packet  without  options  to  an  open  port 


Packet  send 


IPV6 

TRAFFIC  CLASS 

FLOW  LABEL 

PAYLOAD 

HOP  LIMIT 

X 

Y 

20 

255 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

TCP 

HEADER 

20 

FLAGS 

SYN,  FIN 

Windows  Server  2003 

Windows  Server  2003 

Windows  XP  Pro 

Red  Hat  Enterprise 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

Packet  received 

Enterprise  Edition  SPl 

Standard  Edition 

SP2 

Linux  4  WS 

TRAFFIC  CLASS 

0 

0 

0 

0 

0 

0 

0 

FLOW  LABEL 

0 

0 

0 

0 

0 

0 

RANDOM 

IPV6 

PAYLOAD 

24 

24 

24 

24 

24 

24 

24 

NO  REPLY 

HOP  LIMIT 

128 

128 

128 

64 

64 

64 

64 

SEQUENCE 

ISN 

ISN 

ISN 

ISN 

ISN 

ISN 

ISN 

ACKNOWLEDGE 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

SEQ+  + 

HEADER 

24 

24 

24 

24 

24 

24 

24 

TCP 

FLAGS 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

SYN,  ACK 

WINDOW  SIZE 

17080 

17080 

17080 

5760 

5760 

5760 

65535 

OPTIONS 

max  seg  size:  1440 

max  seg  size:  1440 

max  seg  size:  1440 

max  seg  size:  1440 

max  seg  size:  1440 

max  seg  size:  1440 

max  seg  size:  1440 

Table  32.  Test  case  5  modified  from  Queso,  SYN,  FIN  packet  without  options  to  an  open  port 
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Test  Case  6-  Modified  from  Queso 

PSH  packet  without  options  to  an  open  port 


Packet  send 


IPV6 

TRAFFIC  CLASS 

FLOW  LABEL 

PAYLOAD 

HOP  LIMIT 

X 

Y 

20 

255 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

TCP 

HEADER 

20 

FLAGS 

PSH 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro 
SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

TRAFFIC  CLASS 

0 

0 

0 

FLOW  LABEL 

0 

0 

0 

Tn\  Id 

NO  REPLY 

NO  REPLY 

NO  REPLY 

NO  REPLY 

NO  REPLY 

Ir  V  D 

PAYLOAD 

20 

20 

20 

HOP  LIMIT 

128 

128 

128 

SEQUENCE 

0 

0 

0 

ACKNOWLEDGE 

SEQ 

SEQ 

SEQ 

HEADER 

20 

20 

20 

TCP 

FLAGS 

RST,  ACK 

RST,  ACK 

RST,  ACK 

WINDOW  SIZE 

0 

0 

0 

OPTIONS 

-- 

-- 

— 

Table  33.  Test  ease  6  modified  from  Queso,  PSH  paeket  without  options  to  an  open  port 
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Test  Case  7-  Modified  from  Queso 

SYN,  ECN,  CWR  packet  without  options  to  an  open  port 


Packet  send 


IPV6 

TRAFFIC  CLASS 

FLOW  LABEL 

PAYLOAD 

HOP  LIMIT 

X 

Y 

20 

255 

SEQUENCE 

SEQ 

ACKNOWLEDGE 

0 

TCP 

HEADER 

20 

FLAGS 

SYN,  ECN,  CWR 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro 

SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

TRAFFIC  CLASS 

0 

0 

0 

0 

0 

0 

0 

0 

FLOW  LABEL 

0 

0 

0 

0 

0 

0 

RANDOM 

RANDOM 

IPV6 

PAYLOAD 

24 

24 

24 

24 

24 

24 

24 

24 

HOP  LIMIT 

128 

128 

128 

64 

64 

64 

64 

64 

TCP 

SEQUENCE 

ACKNOWLEDGE 

HEADER 

FLAGS 

ISN 

SEQ+  + 

24 

SYN,  ACK 

ISN 

SEQ+  + 

24 

SYN,  ACK 

ISN 

SEQ+  + 

24 

SYN,  ACK 

ISN 

SEQ+  + 

24 

SYN,  ACK 

ISN 

SEQ+  + 

24 

SYN,  ACK 

ISN 

SEQ+  + 

24 

SYN,  ACK 

ISN 

SEQ+  + 

24 

SYN,  ACK 

ISN 

SEQ+  + 

24 

SYN,  ACK 

WINDOW  SIZE 

17080 

17080 

17080 

5760 

5760 

5760 

65535 

65535 

OPTIONS 

max  seq  size:  1440 

max  seq  size:  1440 

max  seq  size:  1440 

max  seq  size:  1440 

max  seq  size:  1440 

max  seq  size:  1440 

max  seq  size:  1440 

max  seq  size:  1440 

Table  34.  Test  case  7  modified  from  Queso,  SYN,  ECN,  CWR  packet  without  options  to  an  open  port 
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3,  Analysis 

From  the  results  presented  in  the  tables  above,  it  is  evident  that  not  all  OSes 
respond  with  the  same  values  in  their  headers  and  there  are  eases  where  they  don’t  even 
exhibit  the  same  behavior.  These  results  parallel  those  found  when  the  two  tools  are  used 
in  an  IPv4  environment.  The  key  points  where  differenees  ean  be  identified  between  the 
responses  or  behavior  of  individual  OSes  are  diseussed  below. 

a.  Window  Size 

The  widow  size  is  aetually  the  buffer  size  in  bytes,  set  at  the  remote  host 
for  this  eonneetion.  This  value  is  an  important  faetor  of  OS  deteetion  beeause  many  OS 
use  a  unique  value  as  eompared  to  the  other  OSes.  Also,  it  was  observed  that  the 
Windows  and  the  Linux  maehines  ehange  their  window  size  value  depending  on  whether 
or  not  the  paeket  sent  to  that  host  ineluded  options,  while  the  FreeBSD  maehine  always 
set  this  value  to  the  maximum  (65535  bytes).  Speeifieally,  Test  Cases  1  and  3  ineluded 
options  in  the  TCP  headers  of  the  paekets  sent  to  the  target  host  and  the  responses 
reeeived  from  the  Windows  maehines  had  the  window  size  value  set  to  17280,  the  Linux 
maehines  set  that  value  to  5712,  and  the  FreeBSD  set  the  value  to  65535.  In  Test  Cases  9, 
13,  and  15,  there  were  no  options  ineluded  in  the  paeket  sent  and  the  responses  reeeived 
from  the  Windows  maehines  had  the  window  size  value  set  to  17080,  the  Linux  maehines 
set  that  value  to  5760,  and  the  FreeBSD  again  set  the  value  to  65535. 

b.  Options 

The  options  field  is  another  key  point  to  differentiate  OSes.  Not  all  OSes 
support  all  options  and  nor  do  they  list  the  supported  options  in  the  same  order.  Windows 
maehines  inelude  in  their  option  field  only  the  “Maximum  Segment  Size”,  where  other 
OSes  may  inelude  more  options.  Furthermore,  it  was  observed  that  though  some  OSes 
support  the  same  options  and  present  them  in  the  same  order,  they  may  support  different 
values  for  the  window  seale,  as  happens  in  the  ease  of  Fedora  Core  4  and  Red  Hat  Linux 
9.0. 

c.  No  Reply 

There  are  some  eases  where  the  RFCs  do  not  speeify  elearly  the 
appropriate  response  from  a  host  reeeiving  some  types  of  paekets.  Thus,  the  developers 
of  the  TCP/IP  staek  may  implement  different  behavior  for  their  OS.  Examples  of  these 
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cases  are  the  test  eases  of  the  NULL  packet,  the  FIN  packet,  and  the  PSH  packet 
deseribed  in  Test  Cases  2,  11,  and  14,  respectively.  In  those  cases,  only  the  Windows 
maehines  sent  back  a  response. 

d.  Hop  Limit  Value 

As  in  the  case  of  IPv4,  the  Windows  OSes  always  set  this  value  to  128  and 
the  other  OSes  always  use  the  value  64.  As  described  with  respeet  to  IPv4,  the  hop  limit 
value  can  only  be  used  to  exelude  OSes.  For  example,  if  the  hop  limit  value  in  a  received 
packet  is  more  than  64  that  host  could  not  be  using  an  OS  that  sets  the  initial  hop  limit 
value  to  64  or  less. 

e.  Traffic  Class 

In  the  test  cases  presented  earlier,  the  traffie  elass  field  of  the  paeket  sent 
to  the  target  machine  was  set  to  a  randomly  selected  value.  However,  many  different 
values  were  tested  but  they  resulted  in  the  same  responses.  From  the  results  reeeived,  it 
seems  that  only  the  FreeBSD  6.0  and  the  MacOS  X  set  this  field  to  a  value  other  than  the 
default,  which  is  “0.”  It  was  observed  that  there  are  eases  where  FreeBSD  may  use  0x0, 
0x3,  0x8,  OxD  or  Oxe  for  the  responses  sent  back.  MacOS  X  set  this  value  to  “0”  when 
the  response  was  to  accept  a  connection  with  the  other  maehine  (SYN,  ACK  packet)  and 
to  the  value  extraeted  from  the  reeeived  packet  in  all  other  cases.  Although  this  value 
seems  to  give  some  clue  about  the  OS,  actually  it  is  not  safe  to  use.  This  is  because  RFC 
2460  mandates,  “An  upper-layer  protocol  must  not  assume  that  the  value  of  the  Traffic 
Class  bits  in  a  received  packet  are  the  same  as  the  value  sent  by  the  packet's  source,” 
because  any  intermediate  node  could  possibly  change  this  value.  So  it  would  be  wise,  at 
least  for  now,  to  not  use  it  for  OS  fingerprinting  beeause  this  field  is  still  under 
experimental  use. 

f  Flow  Label 

Similar  to  the  traffic  class  field,  the  value  used  for  the  flow  label  field  was 
selected  randomly.  While  many  different  values  were  tested  no  difference  was  observed 
in  the  responses.  The  eommon  response  is  for  all  OSes  to  set  this  value  to  “0.”  However, 
FreeBSD  and  MaeOS  X  set  this  field  to  a  random  value  when  they  were  accepting  a 
request  to  establish  a  eonnection.  MaeOS  X  set  this  field  to  the  same  value  as  that  in  the 
packet  reeeived  for  all  other  cases.  The  only  ease  that  was  observed  where  this  value  was 
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set  to  “0”  by  MacOS  was  in  the  case  of  the  ICMPv6  “port  unreachable”  message. 
Possibly  the  other  OSes  do  not  support  this  functionality  and  simply  set  this  value  to  “0” 
as  allowed  by  RFC  2460. 

g.  Payload 

The  payload  value  counts  the  number  of  bytes  included  in  the  data  field  of 
the  IPv6  packet.  Thus,  it  is  closely  related  to  the  amount  of  TCP  options  included  in  the 
packet.  Only  when  the  amount  of  options  carried  in  a  TCP  segment  varies,  it  is  possible 
to  make  a  guess  (but  not  accurate)  about  the  type  of  OS.  In  the  test  cases  described 
earlier,  we  can  characterize  an  OS  belonging  to  a  family  of  OSes  like  Windows  or  Linux. 

h.  ICMPv6 port  Unreachable 

In  the  IPv4  case,  it  was  observed  that  the  amount  of  original  data  sent  back 
from  the  OSes  was  not  constant,  and  this  was  a  factor  for  identifying  the  OS.  In  the  case 
of  IPv6,  the  ICMP  protocol  has  been  replaced  from  the  ICMPv6,  which  is  defined  in  RFC 
2463.  The  “port  unreachable”  message  is  identified  as  a  Type  1  Code  4  message.  In  Test 
Case  8,  a  UDP  packet  sent  to  a  closed  port  included  some  data.  The  OSes  sent  back  an 
ICMPv6  “port  unreachable”  response  but  the  amount  of  original  data  sent  back  never 
exceeded  1184  bytes,  regardless  of  the  amount  of  data  in  the  original  packet.  Further, 
this  behavior  was  observed  for  all  OSes.  The  point  here  is  that  it  is  not  possible  to 
identify  the  OS  based  on  the  amount  of  original  data  included  in  the  ICMPv6  header. 

The  two  tools  explored  by  this  thesis  were  effective  in  providing  clues  to 
the  underlying  OS  used  on  a  target  machine  regardless  of  the  IP  version  encountered  as 
the  tools  use  information  carried  in  the  transport  and  Network  layer  headers.  We  next 
look  to  see  if  the  changes  in  the  IPv6  header  format  open  new  opportunities  to  extract 
information  that  may  lead  to  the  identity  of  the  OS. 
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V.  OS  DETECTION  METHODS  ENABLED  BY  IPV6 


A.  OVERVIEW 

The  research  of  this  thesis  so  far  was  concentrated  on  the  current  methods  for  OS 
fingerprinting  under  IPv4  and  the  feasibility  to  use  these  methods  also  with  IPv6.  In  the 
previous  chapter,  it  was  shown  that  the  existing  methods  for  OS  fingerprinting  on  IPv4 
could  possibly  be  used  on  IPv6.  However,  the  necessary  changes  need  to  be  made  on  the 
IP  header  of  the  packet  so  that  it  conforms  to  the  requirements  of  the  new  protocol.  IPv6, 
however,  introduces  a  new  concept  in  the  overall  protocol  stack  architecture:  the 
extension  headers. 

1.  Optional  Information  In  IPv6 

In  IPv4,  there  was  a  variable-length  optionfield  that  the  originator  of  the  packet 
used  to  request  specific  handling  for  the  packet  by  the  network  or  the  receiver.  In  IPv6, 
this  field  is  no  longer  available.  The  IPv6  header  is  always  40  bytes  long.  However, 
optional  Internet  layer  information  may  be  encoded  in  separate  headers  that  may  be 
placed  between  the  IPv6  header  and  the  upper  layer  header.  There  is  a  small  number  of 
such  extension  headers  defined,  each  identified  by  a  distinct  Next  Header  value.  A  full 
implementation  of  IPv6  includes  the  following  extension  headers: 

•  Hop-by-Hop  options 

•  Routing 

•  Fragment 

•  Destination  options 

•  Authentication 

•  Encapsulation  Security  Payload 

With  exception  of  the  Hop-by-Hop  extension  header,  these  headers  are  not 
examined  or  processed  by  any  node  along  a  packet’s  delivery  path,  until  the  packet 
reaches  the  node  identified  in  the  Destination  Address  field  of  the  IPv6  header.  The  Hop- 
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by-Hop  options  header  is  examined  and  proeessed  by  every  node  along  a  packet’s 
delivery  path.  Each  of  these  extension  headers  is  subject  to  specific  format  requirements. 
The  first  four  of  them  are  specified  in  RFC  2460  and  the  last  two  in  RFCs  2402  and  2406, 
respectively. 

2,  Research  Concept 

This  chapter  concentrates  on  the  possibility  of  OS  fingerprinting  methods  using 
any  of  the  extension  headers.  The  idea  behind  the  use  of  the  extension  headers  in  order  to 
detect  the  OS  is  to  identify  possible  inconsistencies  within  the  guidance  provided  by  the 
RFCs  in  the  way  the  OSes  respond  to  received  packets.  In  a  departure  from  the  methods 
described  in  the  previous  chapter,  we  do  not  observe  the  type  of  information  the  target 
OS  will  include  in  the  IPv6  or  TCP  header.  This  has  been  already  examined.  Also,  the 
objective  of  the  extension  headers  is  to  request  some  type  of  service  from  the  network  or 
the  receiver  of  the  packet.  In  this  case,  the  network  or  the  receiver  could  possibly  provide 
the  requested  type  of  service  or  even  better,  at  least  for  our  purposes,  would  not 
understand  the  requested  type  of  service  and  so  will  respond  with  an  ICMPv6  packet 
pointing  to  the  unrecognized  value.  If  the  requested  type  of  service  is  understood  and 
supported  by  the  receiver,  it  will  handle  the  packet  in  the  appropriate  way  and  proceed  to 
the  next  header,  which  is  either  TCP  or  UDP.  That  means  that  we  will  not  receive  back  a 
packet  with  any  of  the  extension  headers  included.  Another  reason  for  receiving  an 
ICMPv6  response  from  the  target  OS  is  the  case  where  we  craft  and  send  to  the  target  OS 
a  packet  with  an  extension  header  but  with  some  invalid  values  included  in  the  fields  of 
the  extension  headers.  For  those  cases,  RFCs  define  the  appropriate  response  but  it  may 
be  possible  that  the  target  OS  will  not  respond  with  the  expected  response.  The  problem 
with  this  case  is  that  if  the  extension  header  will  be  examined  or  processed  by  any 
intermediate  router,  it  may  be  possible  for  the  packet  to  be  dropped  and  never  reach  its 
destination.  So,  it  is  important  to  ensure  that  the  packet  we  craft  and  send  to  the  target  OS 
will  get  through  the  network  and  reach  the  destination. 
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B.  OS  FINGERPRINTING  METHODS  ENABLED  BY  IPV6  EXTENSION 

HEADERS 

The  following  extension  headers  were  examined  for  utility  in  identifying  the 
remote  OS.  Some  key  identifying  factors  are  described  below: 

1,  Routing  Header 

The  routing  header  is  very  similar  to  IPv4’s  Loose  Source  and  Record  Route 
option.  This  header  is  used  by  the  originator  of  the  packet  to  list  one  or  more  intermediate 
nodes  that  must  be  visited  on  the  way  to  the  destination.  The  format  of  the  Routing 
Header,  as  it  is  specified  in  RFC  2460,  is  presented  in  Figure  14  below. 

Next  Header  i  Hdr  Ext  Len  Routing  Type  Segments  Left 


.  type-specific  data 

I  I 

Figure  14.  Routing  header  format. 

•  Next  header:  8-bit  selector.  Identifies  the  type  of  header  immediately 
following  the  routing  header. 

•  Hdr  Ext  length:  8-bit  unsigned  integer.  Length  of  the  routing  header  in  8- 
octet  units,  not  including  the  first  8  octets. 

•  Routing  type:  8-bit  identifier  of  a  particular  routing  header  variant.  In  RFC 
2460,  only  the  routing  type  “0”  is  described.  Other  routing  types  supported 
or  experimental  are  presented  in  the  Table  35  below. 

•  Segments  left:  8-bit  unsigned  integer.  Number  of  route  segments 
remaining,  i.e.  number  of  explicitly  listed  intermediate  nodes  still  to  be 
visited  before  reaching  the  final  destination. 

•  Type-specific  data:  variable-length  field,  the  format  of  which  is 
determined  by  the  routing  type,  and  of  length  is  such  that  the  complete 
routing  header  is  an  integer  multiple  of  8  octets  long. 
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0  -  Source  Route  (IPV6] 

1  -  Nimrod  [CHARLES  LYNN] 

2  -  Type  2  Routing  Header  (RFC3775] 

253  -  RFC3692-style  Experiment  1  (*)  [RFC-fenner-iana-exp-2780-05.txt] 

254  -  RFC3692-style  Experiment  2  (*)  [RFC-fenner-iana-exp-2780-05.txt] 

Table  35.  Routing  types[  16]. 

For  the  routing  header,  the  following  methods  were  found  that  could  possibly  be  used  as 
a  fingerprint  for  the  target  OS. 

a.  Test  case  1,  Unrecognized  routing  type 

This  method  sends  a  packet  with  a  routing  extension  header  following  the 
IPv6  header  and,  optionally,  the  TCP  header  following  the  routing  header  as  the  upper 
layer  protocol.  The  routing  type  field  is  set  to  an  unrecognized  value  such  as  “OXFF,”  the 
segments  left  field  is  set  to  “1”,  and  the  data  field  set  to  the  “::0”  address.  As  it  is 
specified  in  RFC  2460,  when  the  receiver  of  the  packet,  while  processing  the  routing 
header,  encounters  an  unrecognized  type  it  will  make  the  following  decision  based  on  the 
value  of  the  segments  left  field.  If  the  segments  left  field  is  “0”,  then  the  receiver  will 
ignore  the  routing  header  and  proceed  to  process  the  next  header.  Otherwise,  the  receiver 
will  discard  the  packet  and  send  back  an  ICMPv6  Type  4,  Code  0  (parameter  problem, 
erroneous  header  field  encountered)  message  to  the  originator  of  the  packet  pointing  to 
the  unrecognized  routing  type.  A  summary  of  the  packet  sent  to  each  host  in  the  network 
and  the  responses  received  from  them  is  presented  in  Table  37. 

b.  Test  case2,  Unrouted  address 

This  method  sends  a  packet  with  a  routing  extension  header  following  the 
IPv6  header.  The  routing  type  field  is  set  to  the  default  type  “0”,  the  segments  left  field  is 
set  to  “1”,  and  the  data  field  set  to  the  ;;0  address.  As  it  is  specified  in  RFC  2460,  the  first 
node  to  be  visited  is  the  address  specified  in  the  destination  address  field  in  the  IPv6 
header.  When  the  packet  reaches  that  node,  then  the  same  node  will  have  to  route  the 
packet  through  the  next  address  listed  in  the  type-specific  data  fieldi^of  the  routing 
extension  header.  In  this  case,  that  address  is  considered  unrouted,  thus  the  node  would 
not  be  able  to  forward  the  packet.  The  appropriate  response  for  this  case  is  not  explicitly 


A  list  with  the  addresses  to  be  visited  before  the  paeket  reaches  the  final  destination 

82 


defined  in  RFC  2460  and  the  responses  by  different  OSes  may  vary.  A  summary  of  the 
paeket  sent  to  eaeh  host  in  the  network  and  the  responses  received  from  them  is  presented 
in  Table  38. 

c.  Test  case  3,  Incorrect  extension  header  length 
This  method  also  sends  a  packet  with  a  routing  extension  header  following 
the  IPv6  header  and,  optionally,  the  TCP  header  following  the  Routing  header,  as  the 
upper  layer  protocol.  The  routing  type  field  is  set  to  the  default  type  “0”,  the  segments 
left  field  is  set  to  “2”,  and  the  data  field  contains  the  ;;0  address.  As  specified  in  RFC 
2460,  when  the  receiver  of  the  packet,  while  processing  the  routing  header,  determines 
that  the  segments  left  field  is  greater  than  the  routing  addresses  in  the  routing  extension 
header,  it  should  discard  the  packet  and  send  an  ICMPv6  Type  4,  Code  0  (parameter 
problem,  erroneous  header  field  encountered)  message  to  the  originator  of  the  packet.  A 
summary  of  the  packet  sent  to  each  host  in  the  network  and  the  responses  received  from 
them  is  presented  in  Table  39. 

2,  Destinations  Options  Header 

The  destination  options  header  is  used  to  carry  optional  information  that  needs  to 
be  examined  only  by  a  packet’s  destination  node.  The  format  of  the  destination  options 
header,  as  it  is  specified  in  RFC  2460,  is  presented  in  Figure  15  below. 

+-+-4-+-+-4-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-4 

Next  Header  Hdr  Ext  Len 

4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4  4 


.  Options 

I 

4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4 

Figure  15.  Destinations  options  header. 

•  Next  Header;  8-bit  selector.  Identifies  the  type  of  header  immediately 
following  the  Destination  Options  header. 
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•  Hdr  Ext  Len;  8-bit  unsigned  integer.  Length  of  the  Destination  Options 
header  in  8-octet  units,  not  including  the  first  8  octets. 

•  Options;  Variable-length  field,  of  length  such  that  the  complete  destination 
options  header  is  an  integer  multiple  of  8  octets.  Contains  one  or  more 
Type-Length-Value  (TLV)  encoded  options,  as  described  in  RLC  2460 
section  4.2.  The  format  of  this  field  is  presented  in  Ligure  16  below. 

-  --  --  --  - 

Option  Type  Opt  Data  Lon  Option  Data 

-.4  -  --  --  --  - 

Ligure  16.  TLV  encoded  options  format. 

•  Option  Type;  8-bit  identifier  of  the  type  of  option.  In  RLC  2460,  only  the 
Padl  and  PadN  options  are  described.  Other  supported  options  are 
experimental  as  presented  in  Table  36  below. 

•  Opt  Data  Len;  8-bit  unsigned  integer.  Length  of  the  Option  Data  field  of 
this  option,  in  octets. 

•  Option  Data;  Variable-length  field.  Option-Type-specific  data. 

In  the  destination  header,  one  or  more  options  can  be  included.  Each  one  requires 
a  separate  one  of  the  TLV  encoded  options. 
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HEX 

act 

chg 

rest 

0 

00 

0 

00000 

Padl 

[IPV6] 

1 

00 

0 

00001 

PadN 

[ IPV6 ] 

C2 

11 

0 

00010 

Jumbo  Payload 

( JUMBOCRAM] 

C3 

11 

0 

00011 

Unassigncd 

4 

00 

0 

00100 

Tunnel  Encapsulation  Limit 

[ TUNNEL ] 

5 

00 

0 

00101 

Router  Alert 

[RFC  2711] 

C9 

11 

0 

01001 

Home  Address 

[RFC3775] 

8A 

10 

0 

01010 

Endpoint  Identification 

(CHARLES  LYNN] 

Oxlc 

00 

0 

11110 

RFC3692-style 

Experiment 

/  * 

)  [RFC-fenner-iana-exp-2780-05 . txt ] 

0x3e 

00 

1 

11110 

RFC3692-style 

Experiment 

/  * 

)  [RFC-fenner-iana-exp-2780-05 , txt ] 

0x5c 

01 

0 

11110 

RFC3692-stylo 

Experiment 

/  * 

)  [RFC-fenner-iana-exp-2780-05 . txt ] 

0x7e 

01 

1 

11110 

RFC3692-style 

Experiment 

/  * 

)  [RFC-fenner-iana-exp-2780-05 . txt  J 

0x9c 

10 

0 

11110 

RFC3692-style 

Experiment 

/  * 

)  [RFC-fenner-iana-exp-2780-05 . txt ] 

Oxbc 

10 

1 

11110 

RFC3692-style 

Experiment 

/  * 

)  [RFC-fenner-iana-exp-2780-05 . txt ] 

Oxdc 

11 

0 

11110 

RFC3692-stylc 

Experiment 

( * 

)  [RFC-fenner-iana-exp-2780-05 . txt ] 

Oxfe 

11 

1 

11110 

RFC3692-style 

Experiment 

/  * 

)  [RFC-fenner-iana-exp-2780-05 . txt ] 

Table  36.  Supported  option  types  [16]. 


For  the  Destinations  Options  header  the  following  method  was  found  that  eould  possibly 
be  used  to  fingerprint  a  target  OS. 

a.  Test  case  4,  Unrecognized  destination  type 

This  method  sends  a  packet  with  a  destination  option  extension  header 
following  the  IPv6  header  and,  optionally,  the  TCP  header  following  the  routing  header, 
as  the  upper  layer  protocol.  The  Destination  Type  is  set  to  an  unrecognized  value  for  a 
Destination  Header.  In  this  case  it  was  set  to  0XC2,  which  is  for  the  “Jumbo  Payload,” 
which  is  an  optional  type  supported  only  by  the  hop-by-hop  extension  header.  The  option 
type  codes  are  internally  encoded  such  that  the  their  highest  order  two  bits  specify  the 
action  that  must  be  taken  if  the  processing  IPv6  node  does  not  recognized  the  option  type. 
In  this  case,  the  expected  response  is  to  “discard  the  packet  and,  only  if  the  packet's 
Destination  Address  was  not  a  multicast  address,  send  an  ICMP  Parameter  Problem, 
Code  2,  message  to  the  packet's  Source  Address,  pointing  to  the  unrecognized  Option 
Type.”  [17].  A  summary  of  the  packet  sent  to  each  host  in  the  network  and  the  responses 
received  from  them  is  presented  in  Table  40. 
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Test  Case  1 


Unrecognized  routing  type 

Packet  send 


TRAFFIC  CLASS 

X 

FLOW  LABEL 

Y 

IPV6 

PAYLOAD 

44/2413 

NEXT  HEADER 

0X2B 

(ROUTING) 

HOP  LIMIT 

64 

NEXT  HEADER 

6  (TCP) 

59(NO  NEXT  HEADER) 

LENGTH 

2 

ROUTING 

TYPE 

OXFF 

(UNRECOGNIZED  TYPE) 

SEGMENT  LEFT 

1 

ADDRESS 

::0 

SEQUENCE 

ISN 

ACKNOWLEDGE 

0 

TCP 

FLAGS 

SYN 

HEADER 

20 

OPTIONS 

-- 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

TRAFFIC  CLASS 

0 

0 

0 

0 

0 

0 

0 

0 

FLOW  LABEL 

0 

0 

0 

0 

0 

0 

0 

0 

IPV6 

PAYLOAD 

92/72 

92/72 

92/72 

92/72 

92/72 

92/72 

92/72 

92/72 

HOP  LIMIT 

128 

128 

128 

64 

64 

64 

64 

64 

TYPE 

4 

4 

4 

4 

4 

4 

4 

4 

CODE 

0 

0 

0 

0 

0 

0 

0 

0 

POINTER 

0X2A 

0X2A 

0X2A 

0X2A 

0X2A 

0X2 

0X2A 

0X2A 

ICMPv6 

PARAMETER  PROBLEM 
MESSAGE 

ERRONEOUS  HEADER 
FIELD  ENCOUNTERED 

Table  37.  Test  ease  1,  Unrecognized  routing  type. 
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44  Bytes  when  there  is  TCP  header  and  24  Bytes  when  there  is  no  TCP  header  following  the  Routing  extension  header 
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Test  Case  2 


Unrouted  address 


Packet  send 


TRAFFIC  CLASS 

X 

FLOW  LABEL 

Y 

IPV6 

PAYLOAD 

44/24 

NEXT  HEADER 

0X2B 

(ROUTING) 

HOP  LIMIT 

64 

NEXT  HEADER 

6  (TCP) 

59(NO  NEXT  HEADER) 

LENGTH 

2 

ROUTING 

TYPE 

0 

SEGMENTS  LEFT 

1 

ADDRESS 

::0 

SEQUENCE 

ISN 

ACKNOWLEDGE 

0 

HEADER 

20 

TCP 

FLAGS 

SYN 

OPTIONS 

-- 

Windows  Server  2003 

Windows  Server  2003 

Windows  XP  Pro  SP2 

Red  Hat  Enterprise 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

Packet  received 

Enterprise  Edition  SPl 

Standard  Edition 

Linux  4  WS 

TRAFFIC  CLASS 

0 

0 

0 

FLOW  LABEL 

0 

0 

0 

IPV6 

PAYLOAD 

92 

92 

92 

NO  REPLY 

NO  REPLY 

NO  REPLY 

NO  REPLY 

NO  REPLY 

HOP  LIMIT 

128 

128 

128 

TYPE 

4 

4 

4 

CODE 

0 

0 

0 

POINTER 

0x30 

0x30 

0x30 

ICMPv6 

PARAMETER 

PROBLEM  MESSAGE 
ERRONEOUS 

HEADER  FIELD 

ENCOUNTERED 

Table  38.  Test  ease  2,  Unrouted  Address. 
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Test  Case  3 


Incorrect  extension  header  length 

Packet  send 


TRAFFIC  CLASS 

X 

FLOW  LABEL 

Y 

IPV6 

PAYLOAD 

24 

NEXT  HEADER 

0X2B 

(ROUTING) 

HOP  LIMIT 

64 

NEXT  HEADER 

59(NO  NEXT  HEADER) 

LENGTH 

1 

ROUTING 

TYPE 

0 

SEGMENTS  LEFT 

2 

ADDRESS 

::0 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

TRAFFIC  CLASS 

0 

0 

0 

0 

0 

0 

0 

0 

FLOW  LABEL 

0 

0 

0 

0 

0 

0 

0 

0 

IPV6 

PAYLOAD 

72 

72 

72 

72 

72 

72 

72 

72 

HOP  LIMIT 

128 

128 

128 

64 

64 

64 

64 

64 

TYPE 

4 

4 

4 

4 

4 

4 

4 

4 

ICMPv6 

CODE 

0 

0 

0 

0 

0 

0 

0 

0 

POINTER 

0X29 

0X29 

0X29 

0X29 

0X29 

0X1 

0X29 

0X29 

Table  39.  Test  case  3,  Incorrect  extension  header  length. 
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Test  Case  4 


Unrecognized  destination  type 

Packet  send 


TRAFFIC  CLASS 

X 

FLOW  LABEL 

Y 

IPV6 

PAYLOAD 

28/8 

NEXT  HEADER 

0X3C 

(DESTINATIONS) 

HOP  LIMIT 

64 

NEXT  HEADER 

6  (TCP) 

59(NO  NEXT  HEADER) 

DESTINATION 

LENGTH 

0 

TYPE 

0XC2 

(JUMBO  PACKET) 

SEQUENCE 

ISN 

ACKNOWLEDGE 

0 

TCP 

FLAGS 

SYN 

HEADER 

20 

OPTIONS 

-- 

Packet  received 

Windows  Server  2003 
Enterprise  Edition  SPl 

Windows  Server  2003 
Standard  Edition 

Windows  XP  Pro  SP2 

Red  Hat  Enterprise 
Linux  4  WS 

FEDORA  CORE  4 

Red  Hat  Linux  9.0 

FreeBSD  6.0 

MAC  OS  X 

TRAFFIC  CLASS 

0 

0 

0 

0 

0 

0 

0 

0 

IPV6 

FLOW  LABEL 

0 

0 

0 

0 

0 

0 

0 

0 

PAYLOAD 

76 

76 

76 

76 

76 

76 

76 

76 

HOP  LIMIT 

128 

128 

128 

64 

64 

64 

64 

64 

TYPE 

4 

4 

4 

4 

4 

4 

4 

4 

CODE 

0 

0 

0 

2 

2 

2 

2 

2 

ICMPv6 

POINTER 

0X2A 

0X2A 

0X2A 

PARAMETER 

PROBLEM  MESSAGE 
ERRONEOUS 

HEADER  FIELD 

ENCOUNTERED 

0X2A 

PARAMETER 

PROBLEM  MESSAGE 
UNRECOGNIZED  IPV6 
OPTION 

ENCOUNTERED 

0X2A 

0X2A 

0X2A 

0X2A 

Table  40.  Test  ease  4,  Unreeognized  destination  type. 
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C.  ANALYSIS 

From  the  results  above,  it  is  evident  that  not  all  OSes  respond  with  the  same 
values  in  their  headers  and  there  are  cases  where  their  behavior  is  different.  The 
common  characteristic  of  the  methods  described  in  the  test  cases  earlier  is  that  all  of 
them  trigger  the  target  host  to  respond  with  an  ICMPv6  message.  Although  the  RFCs 
provide  explicit  guidance  as  to  the  appropriate  response  for  most  of  the  cases,  the  OSes 
do  show  some  deviation  from  that  guidance.  The  various  differences  that  were  explored 
in  the  previous  chapter  regarding  the  IPv6  header  appear  in  these  cases  also  and  are  not 
discussed  again.  However,  the  differences  that  are  identified  by  examining  the  responses 
in  the  ICMPv6  headers  are  discussed  below. 

1.  ICMPv6  Pointer  Value 

The  pointer  value  placed  in  an  ICMPv6  message  sent  by  a  node  points  to  the 
unrecognized  field  of  the  original  packet  received  by  that  node.  In  Test  Cases  1  and  3, 
almost  all  OSes  sent  an  ICMPv6  message  Type  4  Code  0  to  the  originator  of  the  packet 
pointing  to  the  0x2A  and  0x29  respectively,  which  are  the  routing  type  and  segments  left 
fields  of  the  original  packet.  An  exception  was  observed  for  Red  Hat  Linux  9.0,  which 
includes  different  values  for  the  pointer  fields,  0x2  and  0x1  respectively.  It  appears  that 
Red  Hat  Linux  9.0  still  points  to  the  same  unrecognized  fields  but  starts  the  counting  of 
the  bytes  in  the  original  packet  from  the  first  byte  of  the  routing  extension  header, 
offsetting  it  by  40  bytes  compared  with  the  values  inserted  by  the  other  OSes. 

2.  No  Reply 

In  Test  Case  2,  the  address  included  in  the  routing  header  that  is  supposed  to  be 
visited  on  the  path  to  reach  the  destination  node  cannot  be  routed.  This  case  is  not 
explicitly  covered  in  RFC  2460  and  we  observe  that  only  the  Windows  machines 
respond  with  an  ICMPv6  message  Type  4,  Code  0  (parameter  problem  erroneous  header 
field  encountered)  pointing  to  the  0x30  nyte  of  the  original  packet.  This  byte  is  part  of 
the  IPv6  address  included  in  the  routing  header,  which  we  set  to  “::0”.  It  is  actually  the 
first  byte  after  the  initial  64-bit  prefix.  This  is  because  the  smallest  prefix  in  an  IPv6 
address  is  64  bits  and  we  set  it  to  “0.”  When  the  node  examines  the  prefix  value  and 
finds  that  it  is  zero,  it  determines  that  it  cannot  process  the  packet  and  sends  back  the 
error  message  to  the  source  address. 
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3.  ICMPv6  Code  Value 

In  Test  Case  4,  we  observe  a  slightly  different  response  between  the  Windows 
maehines  and  the  rest  of  the  OSes.  Windows  responds  with  an  ICMPv6  Type  4,  Code  0 
and  the  rest  of  the  OSes  send  baek  an  ICMPv6  Type  4,  Code  2  message.  This  is  an 
example  of  what  ean  be  interpreted  differently  by  different  vendors  of  the  OSes.  It  is 
evident  in  both  oases  that  this  paoket  ean  not  be  prooessed  and  the  problem  is  at  the 
destination  option  type  0XC2  (jumbo  payload).  The  jumbo  payload  option  is  supported 
only  by  the  hop-by-hop  extension  header,  so  Windows  maehines  on  the  one  hand 
assume  that  the  0XC2  value  is  erroneous  for  this  extension  header  (destination  header) 
and  the  other  OSes,  on  other  hand,  eonsider  this  value  as  unreeognized. 

It  ean  be  eoneluded,  then,  that  the  extension  headers  may  provide  opportunities 
for  fingerprinting  the  target  host  OS.  While  this  list  of  teehniques  indieate  the  fertility  of 
IPv6  extension  headers  for  elieiting  information  about  the  OSes  employed  on  a  network, 
it  is  not  eomprehensive  as  other  teehniques  may  be  used  whieh  were  not  explored  in  this 
thesis 
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VI.  CONCLUSIONS 


The  objective  of  OS  fingerprinting  is  to  identify  the  OS  type  a  target  machine  is 
running  from  a  remote  machine.  OS  fingerprinting  is  feasible  because  developers  of 
different  OSes  may  interpret  the  guidance  provided  by  the  RFCs  differently,  and 
consequently  their  network  protocol  stack  implementation  may  generate  responses 
bearing  unique  markers  to  certain  probing  packets.  The  key  part  of  OS  fingerprinting  is 
the  finding  of  suitable  probing  packets  for  different  OSes.  Effective  OS  fingerprinting 
tools  have  been  developed  for  probing  hosts  running  the  IPv4  protocol  stack.  This  thesis 
has  shown  that  the  methods  used  by  these  tools  can  also  be  used  for  probing  a  host  that 
runs  an  IPv6  protocol  stack  and  that  IPv6  extension  headers  could  enable  additional 
methods  for  OS  fingerprinting. 


A,  CONCLUSIONS 

Tables  41  and  42  below  summarize  the  results  presented  in  Chapter  IV  and  V. 
They  indicate  the  effectiveness  of  each  method  evaluated  in  this  thesis,  in  terms  of  its 
ability  to  fingerprint  the  OS  type  of  a  host  known  to  run  an  IPv6  protocol  stack..  For 
example,  by  applying  the  first  TCP/UDP  based  method  on  the  selected  set  of  OSes  we 
have  identified  five  different  fingerprints,  each  one  associated  with  a  particular  OS  or  a 
set  of  OSes.  Note  that  after  a  brief  description  of  each  method  are  two  page  numbers: 
one  pointing  to  where  the  detail  of  the  probing  packet  is  given  and  the  other  pointing  to 
where  the  detail  of  the  response  packets  from  different  OSes  is  presented. 
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Methods  Tested 


Sets  of  OSes  with  Unique  Fingerprint 


TCP/UDP 

based 
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o3  rv 
& 
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MS  Server  2003  Enterprise/Standard,  Windows  XP  Pro 
Red  Hat  Enterprise  Einux  4  WS,  Eedora  Core  4 
Red  Hat  Einux  9.0 
EreeBSD  6.0 
MAC  OS  X 

MS  Server  2003  Enterprise/Standard,  Windows  XP  Pro 

Red  Hat  Enterprise  Einux  4  WS,  Eedora  Core  4,  Red  Hat 
Einux  9.0,  EreeBSD  6.0,  MAC  OS  X 


MS  Server  2003  Enterprise/Standard,  Windows  XP  Pro 
Red  Hat  Enterprise  Einux  4  WS,  Eedora  Core  4 
Red  Hat  Einux  9.0 
EreeBSD  6.0 
MAC  OS  X 

MS  Server  2003  Enterprise/Standard,  Windows  XP  Pro 

Red  Hat  Enterprise  Einux  4  WS,  Eedora  Core  4,  Red  Hat 
Einux  9.0,  EreeBSD  6.0 

MAC  OS  X 
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MS  Server  2003  Enterprise/Standard,  Windows  XP  Pro 

Red  Hat  Enterprise  Einux  4  WS,  Eedora  Core  4,  Red  Hat 
Einux  9.0,  EreeBSD  6.0 

MAC  OS  X 


MS  Server  2003  Enterprise/Standard,  Windows  XP  Pro 

Red  Hat  Enterprise  Einux  4  WS,  Eedora  Core  4,  Red  Hat 
Einux  9.0,  EreeBSD  6.0 

MAC  OS  X 


MS  Server  2003  Enterprise/Standard,  Windows  XP  Pro 

Red  Hat  Enterprise  Einux  4  WS,  Eedora  Core  4,  Red  Hat 
Einux  9.0 

EreeBSD  6.0 

MAC  OS  X 

MS  Server  2003  Enterprise/Standard,  Windows  XP  Pro 

Red  Hat  Enterprise  Einux  4  WS,  Eedora  Core  4,  Red  Hat 
Einux  9.0,  EreeBSD  6.0,  MAC  OS  X 
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MS  Server  2003  Enterprise/Standard,  Windows  XP  Pro 

Red  Hat  Enterprise  Einux  4  WS,  Eedora  Core  4,  Red  Hat 
Einux  9.0 

EreeBSD  6.0,  MAC  OS  X 


MS  Server  2003  Enterprise/Standard,  Windows  XP  Pro 

Red  Hat  Enterprise  Einux  4  WS,  Eedora  Core  4,  Red  Hat 
Einux  9.0,  EreeBSD  6.0 

MAC  OS  X 


MS  Server  2003  Enterprise/Standard,  Windows  XP  Pro 

Red  Hat  Enterprise  Einux  4  WS,  Eedora  Core  4,  Red  Hat 
Einux  9.0,  EreeBSD  6.0,  MAC  OS  X 


MS  Server  2003  Enterprise/Standard,  Windows  XP  Pro 

Red  Hat  Enterprise  Einux  4  WS,  Eedora  Core  4,  Red  Hat 
Einux  9.0,  EreeBSD  6.0 

MAC  OS  X 
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MS  Server  2003  Enterprise/Standard,  Windows  XP  Pro 

Red  Hat  Enterprise  Einux  4  WS,  Eedora  Core  4,  Red  Hat 
Einux  9.0 

EreeBSD  6.0 

MAC  OS  X 


MS  Server  2003  Enterprise/Standard,  Windows  XP  Pro 

Red  Hat  Enterprise  Einux  4  WS,  Eedora  Core  4,  Red  Hat 
Einux  9.0,  EreeBSD  6.0,  MAC  OS  X 


MS  Server  2003  Enterprise/Standard,  Windows  XP  Pro 

Red  Hat  Enterprise  Einux  4  WS,  Eedora  Core  4,  Red  Hat 
Einux  9.0 

EreeBSD  6.0,  MAC  OS  X 


Table  41 .  Consolidated  results  from  using  UDP/TCP  methods. 


97 


Methods  Tested 


Sets  of  OSes  with  Unique  Fingerprint 


•a  ^ 

8  & 

(U  & 


a>  o 

^  a 

cd  ^ 


MS  Server  2003  Enterprise/Standard,  Windows  XP  Pro 

Red  Hat  Enterprise  Einux  4  WS,  Eedora  Core  4,  EreeBSD 
6.0,  MAC  OS  X 


Red  Hat  Einux  9.0 


1 .  MS  Server  2003  Enterprise/Standard,  Windows  XP  Pro 

2.  Red  Hat  Enterprise  Einux  4  WS,  Red  Hat  Einux  9.0, 
Eedora  Core  4,  EreeBSD  6.0,  MAC  OS  X 


IPv6 

extension 

headers 

based 


A.  MS  Server  2003  Enterprise/Standard,  Windows  XP  Pro 

B.  Red  Hat  Enterprise  Einux  4  WS,  Eedora  Core  4,  EreeBSD 
6.0,  MAC  OS  X 


C.  Red  Hat  Einux  9.0 


A.  MS  Server  2003  Enterprise/Standard,  Windows  XP  Pro 

B.  Red  Hat  Enterprise  Einux  4  WS,  Red  Hat  Einux  9.0, 
Eedora  Core  4,  EreeBSD  6.0,  MAC  OS  X 


&  '+h‘ 


Table  42.  Consolidated  results  from  using  IPv6  extension  header. 
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The  following  conclusions  can  be  drawn  from  the  results  summarized  in  the  tables 
above: 


•  Tools  developed  in  the  IPv4  environment  can  be  used  to  fingerprint  an  IPv6  host 
effectively.  They  are  able  to  differentiate  a  majority  of  the  OSes  in  the  selected 
test  set.  However,  they  can  no  longer  be  used  to  distinguish  XP  Pro  from  the 
other  two  server  versions  of  Microsoft  Windows.  This  might  be  because  all 
three  versions  of  Windows  are  bundled  with  the  same  IPv6  code.  The 
confirmation  is  left  for  further  study. 

•  The  IPv6  extension  header  based  methods  seem  not  as  effective  as  the  UDP/TCP 
based  methods.  The  methods  tried  for  this  thesis  trigger  the  same  responses  from 
Red  Hat  Enterprise  Linux  4  WS,  Fedora  Core  4,  FreeBSD  6.0,  and  MAC  OS  X. 
Again,  it  might  be  because  all  these  OSes  have  borrowed  the  same  code  base. 
More  work  is  required  in  this  area  to  either  confirm  this  conjecture  or  develop 
more  effective  fingerprinting  probes. 

•  None  of  the  methods  tried  in  this  thesis  can  distinguish  between  Red  Hat 
Enterprise  4  WS  and  Fedora  Core  4.  This  is  true  even  in  the  IPv4  environment. 

Another  point  of  significant  concern  for  OS  fingerprinting  methods  is  the  lack  of 
tools  for  crafting  IPv6  packets.  IPv6  is  still  experimental  and  there  are  not  many  tools 
available  with  an  easy-to-use  interface.  In  this  thesis  SmartBits  6000C  was  used.  There 
were,  however,  cases  where  the  crafting  had  to  be  done  manually  and  the  appropriate 
values  provided  in  hexadecimal  format.  This  is  a  very  time  consuming  process  because  a 
single  incorrect  value  may  make  the  packet  unusable  or  un-routable. 


B,  FUTURE  RESEARCH 

An  important  aspect  that  is  crucial  for  OS  fingerprinting  is  the  size  of  the 
database  holding  the  known  fingerprints.  A  larger  database  would  lead  to  more  accurate 
inferences  about  the  target  OS.  Thus,  it  is  important  to  build  a  database  with  as  many 
fingerprints  as  possible.  Each  OS  explored  should  be  added  to  the  database.  It  was 
noted  that  Nmap  includes  about  1,500  fingerprints  in  its  database.  From  our  study  we 
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concluded  that  no  single  method  provides  definitive  fingerprint  for  all  OSes  in  an  IPv6 
environment.  An  application  could  be  developed  to  exploit  all  these  methods  and 
maintain  a  fingerprint  database  specifieally  for  IPv6  hosts,  iteratively  applying  probes  to 
refine  eaeh  inference  and  so  automate  the  proeess  of  reeognizing  an  OS. 

Another  limitation  of  this  work  is  that  only  a  few  extension  headers  of  IPv6  were 
evaluated.  This  is  largely  due  to  the  faet  that  many  of  the  supported  options  are  still 
experimental  and  thus  they  are  not  fully  defined.  It  should  be  beneficial  to  revisit  this 
issue  when  the  speeifieations  of  IPv6  extension  headers  become  more  conerete  and  more 
stable. 

Finally,  not  all  of  the  methods  described  in  Chapters  IV  and  V  were  effeetive. 
However,  we  should  not  eonelude  that  these  methods  are  absolutely  without  merit.  The 
OSes  sample  used  is  not  large  enough  to  be  considered  exhaustive.  These  methods  may 
be  more  suceessful  against  other  OSes.  Thus,  one  possible  way  to  extend  this  research 
could  be  the  applieation  of  the  methods  deseribed  in  this  thesis  to  additional  OSes  so 
that  we  can  have  a  better  idea  about  which  methods  are  useful  and  whieh  are  not. 
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